Wiki - XP-nNL 1

Johan Wester gaf middels een presentatie aan dat er problemen ontstaan met de standaard manier van unit testen via frameworks als JUnit (Java) en DUnit (Delphi). Hij ziet 5 problemen:

* Als we elke class willen testen moeten we ook de classes die de class gebruikt testen: dat betekent dat je pas kunt testen als grote delen van de applicatie al geschreven zijn. De praktijk leert dat uitstel met het schrijven van testcode vaak leidt tot afstel.

* Bovendien leidt dit uiteindelijk tot testen die niet een kleine unit (class/method) testen maar een volledig systeem (integratietest).

* Classes roepen databases, middleware server, directory services en dergelijke aan. Deze infrastructuur is wellicht niet beschikbaar tijdens het ontwikkelen.

* De infrastructuur maakt bovendien dat de test erg lang kan duren.

* Negatief testen, bijvoorbeeld of de juiste exceptie gegooid wordt als de database offline is, vereist controle over de infrastructuur. Deze controle heeft de ontwikkelaar niet altijd.

De oplossing kan gezocht worden in het gebruik van Mock classes. Dit zijn een soort dummy classes waarin nagenoeg niets gebeurt en dus geen infrastructuur wordt aangeroepen. Wil je een class testen die andere classes nodig heeft, dan gebruik je mock classes voor die andere classes. Dit vereist wel dat die classes meegegeven kunnen worden aan de class-under-test, bijvoorbeeld door ze mee te geven in de constructor.

Voor meer informatie om Mock classes te genereren in Java zie http://www.mockmaker.org. De gegenereerde Mock classes kunnen worden geladen met bepaalde data die de getters vervolgens teruggeven aan de class-under-test. Ook kan gecheckt worden of de class-under-test de mock class niet te vaak of juist te weinig aanroept.

Integratie-testen

Wanneer we Mock classes gebruiken bij unit-testen dan is de unit-test-suite niet te gebruiken als integratie-test-suite. Een integratie-test gebruikt namelijk juist wel andere echte classes om te zien of ze samen tot het gewenste gedrag leiden. Dit betekent dat er naast de unit-testen ook integratie-testen geschreven moeten worden. Veel mooier zou natuurlijk zijn als we door middel van een runtime switch, de unit-test geen Mock classes maar de echte classes kunnen laten gebruiken. Deze opzet vereist verdere studie.

Acceptatie-testen

Uit de discussie bleek dat organisaties waarin tijdens het ontwikkelen geen unit-testen worden geschreven, vaak zeer elementaire bugs pas vinden tijdens het acceptatie-testen. De oplossing is om de ontwikkelaars of testers zover te krijgen dat ze automatisch herhaalbare tests gaan schrijven tijdens of zelfs voordat de code wordt gemaakt. Het gebruiken van frameworks zoals JUnit stimuleert deze manier van werken, omdat de testcode grotendeels gegenereerd kan worden. Het veranderen van de werkwijze tijdens het ontwikkelen vereist natuurlijk een actieve buy-in van het management met name van de manager van het ontwikkelteam.

Verder kwam ter sprake dat tijdens acceptatie-testen soms blijkt dat er iets gebouwd is, wat eigenlijk niet voldoet aan de verwachtingen. Dit kan opgelost worden door tijdens het opstellen van de requirements (de user stories), de eindgebruiker sterk te betrekken. Bovendien kan tijdens het bouwen door middel van rapid protyping, voortdurend worden gecheckt of het gebouwde produkt voldoet aan de verwachtingen. Dit betekent eigenlijk dat de eindgebruiker deel wordt van het ontwikkelteam. In de praktijk gebeurt dit niet vaak.

tzt