Links

  • 1. Sogeti
  • 2. JBoss
  • 3. IBM
  • 4. Oracle
  • 5. SpringSource
  • 6. NL-JUG
  • 7. Java

Archives

Syndication  RSS 2.0

RSS 1.0
RSS 2.0

Bookmark this site

Add 'JCN Blog' site to delicious  Add 'JCN Blog' site to technorati  Add 'JCN Blog' site to digg  Add 'JCN Blog' site to dzone

Posted by Eric Gunnewegh at 22:40 on Wednesday 14 March    Add 'TestNG' site to delicious  Add 'TestNG' site to technorati  Add 'TestNG' site to digg  Add 'TestNG' site to dzone

TestNG staat voor Next Generation Testing. Cedric Beust en Alexandru Popescu zijn co-founders van het TestNG framework en waren op de Qcon om hierover te vertellen. De volgende zaken zijn besproken:

- Groups: Via annotaties kunnen testcases in groepen ingedeeld worden zodat deze groepsgewijs getest kunnen worden. Testcases kunnen in meerdere groepen voorkomen. Met een juiste naamgeving van groepen, kun je met wildcards aangeven wat je wil testen.

- Data providers: Data om te testen wordt gescheiden van de code. Data kan afkomstig zijn van Java files, flat files, de database, etc. Via annotaties kun je aangeven welke data provider je wilt gebruiken per testcase.

- Dependency: Bij een testcase kan het succes van de uitvoering hiervan afhankelijk zijn van het slagen van andere testcases. Indien dit het geval is, zie je bij het niet slagen van een test liever dat de afhankelijke tests overgeslagen zijn dan dat ze ook niet geslaagd zijn. Met annotaties kun je dergelijke afhankelijkheden aangeven. Naast het afhankelijk maken van individuele testcases, kunnen ook groepen als zijnde afhankelijk aangemerkt worden.

Verder kwam tijdens de presentatie aan de orde dat je bij het design al rekening moet houden met de testbaarheid van de code. Twee vijanden van de testbaarheid die de sprekers noemden zijn statische en globale variabelen en een te extreme encapsulatie. Oplossingen hiervoor zijn respectievelijk:
- Dependency Injection, bijvoorbeeld met het Guice framework of Spring.
- Verminder de encapsulatie door meer gebruik te maken van package visibility

Tot slot was het interessant om te horen dat de sprekers vonden dat Test Driven Development niet heilig is. De argumenten die genoemd werden tegen TDD:
- je bent meer geneigd tot micro-design dan tot macro-design
- het is moeilijk om dit in de praktijk vol te houden
- er werd in tijfel getrokken of TDD wel degelijk leidt tot betere kwaliteit.

Uit een kleine enquete onder de toehoorders bleek in ieder geval dat TDD developers duidelijk in de minderheid waren. Met de volgende uitspaak werd de rest (en ik ook) gerust gesteld…

Don’t feel bad if you are not using TDD


© 2020 Java Competence Network. All Rights Reserved.