Praktisch Test Driven Development

Test Driven Development (TDD) is een aspect dat uit de XP is voortgekomen. Iedereen weet wel
ongeveer wat TDD is, maar bij een juist gebruik kan het veel meer voordelen hebben, zoals: concretere
functionele beschrijvingen, minder tijd nodig voor de acceptatietesten, en last but not least,
bij toekomstige aanpassingen en uitbreidingen eenvoudiger regressietesten.
Maar wat is nu een juiste aanpak voor het ontwikkelen van de testen? Dit kun je niet overlaten aan
het toeval of aan de persoonlijke voorkeur van de ontwikkelaar. Daarom is een ‘test strategie’ een
goede aanpak. De strategie die wij toepassen is heel concreet en gericht op compleetheid. Daarbij
komen ook zaken als hergebruik (van de testen) door middel van aanbrengen van hiërarchie en
structuur.
De test strategie bouwt vanaf onderaf op: zorgen voor een stevig fundament om daarop verder te
bouwen. Met behulp van interfaces wordt een vaste manier van testen ‘afgedwongen’. Bij het testen
van de DAO’s maken we gebruik van een test strategie gebaseerd op het Strategy pattern.

Vereiste voorkennis:
Iets van Java programmeren en iets van JUnit

Structurele beschrijving van de opbouw van de presentatie:
Inleiding TDD
Waar komt TDD vandaan
Toepassen van TDD
Vanaf Functioneel Ontwerp
Programmacode testen
Regressietesten
Wat wordt er getest?
Hoeveel wordt er getest
Coverage 80, 90, 95 of 100%
Welke lagen (presentation, service, or persistency
layer)
Wie bepaald de inhoud van de testen?
Functioneel ontwerp
Acceptatie testers
Programmeur
Is dit genoeg?
Mogelijk wel
Maar hoe krijgen we zekerheid?
TEST STRATEGIE
Test strategie
Implementatie van een “test interface”
Iedere test bestaat uit vaste onderdelen
Voorbeeld: DAO’s (persistancy layer)
Wat moet getest worden op de persistency layer?
CRUD! (Create, Read, Update, Delete)
Is dat nou alles?
Nee: hoe om te gaan met referentiele integriteit?
Parent – Child relaties
Bijvoorbeeld vragen als:
Kan ik objecten aanmaken in een 1 op n
relatie?
Als er child objecten zijn, wat gebeurt er bij delete?
Referentiele integriteittest
Maak parent aan
Doe de test
Delete parent
Paar niveaus dieper:
Create de parent van de parent van de parent
Create parent de parent
Create parent
Doe de test
Delete de parent
Delete de parent van parent
Delete de parent van de parent van de parent
Dit moet slimmer kunnen!
Strategie
Ieder test object heeft een “setup” en een “tierdown”
Deze kunnen achtereenvolgens worden aangeroepen
Ieder object kan zorgen dat zijn parent een setup
doet.
Dat object kan hetzelfde bij zijn parent.
Doe de CRUD test
Verwijder parent en de eventuele eerder aangemaakte
parent
Praktisch
Vaste testaanpak
Herbruikbaar en stapelbaar
Pak testen aan als programmeren
Gebaseerd op strategy pattern
Conclusie
Systematische aanpak
Meer dan alleen coverage