Test Driven Development (TDD)

Test Driven Development (TDD), is een ontwikkelmethode waarbij men eerst tests schrijft alvorens de code. In deze blog post leggen we uit hoe dit werkt, wat de voor- en nadelen zijn en hoe het wordt toegepast.

Wat is Test Driven Development?

Het is een ontwikkelmethode waar we als eerst onze manier van aanroepen en het verwachte resultaat defineren. De naam Test Driven Development komt van Kent Back, die hier in 2003 een boek over heeft uitgebracht. Hierin staat een ontwikkelcyclus beschreven om Test Driven Development toe te passen.

Verschillende test tools

Een van de meest gebruikte test tools in PHP is PHPUnit. Hiermee kunnen stukken PHP codes getest worden. Zelf maken we gebruiken van 3 soorten tests:

Feature tests

Een feature test is een test van een nieuwe ontwikkeling binnen een toepassing die we in de browser kunnen testen. Hierdoor kunnen we meteen bepaalde resultaten meten.

Unit tests

De unit tests zijn meestal wat moeilijk te beschrijven, omdat die op een gebruiker of een object plaatsvinden. Hier moet heel nauwkeurig getest worden, omdat in de toepassing hier veel gebruik van wordt gemaakt.

Browser tests

De browser test wordt daadwerkelijk in de browser uitgevoerd. Dit gaat geheel automatisch en we kunnen alles hiermee testen. Van simpele pagina's tot het testen van chat applicaties.

Voordelen

Enkele voordelen van Test Driven Development zijn:

• Er wordt gekeken vanuit het perspectief van de gebruiker. De requirements zijn namelijk gebaseerd op de gebruiker, waardoor we ook snel de interfaces kunnen testen.
• We letten specifiek op de requirements, waardoor er geen overbodige code wordt geschreven.
• De klant krijgt meer vertrouwen, omdat er in het begin al getest wordt.
• Aangezien de onderdelen van de code los geschreven en getest worden is de afhankelijkheid kleiner en daarom minder complex.

Nadelen

Er zijn ook nadelen van Test Driven Development:

• Als een programmeur een specificatie over het hoofd ziet, dan kan het zo zijn dat dit niet in de test en de code zit, waardoor de test eigenlijk mislukt.
• Als alle tests zouden slagen, dan zou je zeggen dat de applicatie naar behoren werkt. Dat is niet helemaal waar, omdat we nu alleen de applicatie hebben getest. We hebben niet getest op integratie- en systeemtests.

De ontwikkelcyclus

Wij gebruiken de volgende ontwikkelcyclus om onze toepassingen te testen:

1. Een test maken

Voordat we code gaan schrijven, maken we eerst een test met daarbij de benodigde requirements.

2. Test draaien en kijken of de aangemaakte test mislukt

Nadat we onze test hebben aangemaakt, gaan we kijken of deze werkt. De eerste keer zal dit nooit mogen slagen, omdat we niet het gewenste resultaat hebben en omdat er toepassingen ontbreken. Het falen van een test is heel belangrijk om na te gaan of de test effectief genoeg is (de test mag geen fouten bevatten en niet altijd slagen).

3. Code schrijven

In deze stap schrijven we onze code om de test die we hebben aangemaakt te laten slagen. Hier gaan we dus echt programmeren. De code mag alleen functionaliteit bevatten die de code laat slagen.

4. Test draaien en kijken of de aangemaakte test slaagt

Hier gaan we kijken of de gemaakt code ervoor zorgt dat de test slaagt. Is de test geslaagd? Dan kunnen we verder naar de volgende stap. Is de test niet geslaagd? Dan herhalen we stap 3 en 4 net zo lang totdat de test slaagt.

5. Code herschrijven (refactoren)

Om te zorgen dat onze code goed leesbaar is voor onze andere ontwikkelaars, herschrijven we de code om het voor ons nog makkelijker te maken.

Testen, testen, testen

Dat testen belangrijk is, staat buiten kijf. Zeker in onze branch is testen van essentieel belang. TDD is een van de manieren waarop tests kunnen worden uitgevoerd. Er zijn natuurlijk nog veel meer varianten. Wij hebben vanuit ons internetbureau gekozen voor TDD.