Enkele principes rond en tips omtrent TDD

TDD: eerst de test, dan de rest

TDD of Test-Driven Development laat developers toe om eerst tests te schrijven en pas dan de code. Het grote voordeel hierbij is uiteraard dat je als developer meer zelfvertrouwen krijgt bij het optimaliseren van bestaande code. Bovendien geeft TDD je meer gelegenheid om na te denken over de structuur van applicatie en code, en de snelheid van (onderdelen van) de applicatie te testen.
Heel wat troeven dus, maar zijn er ook nadelen aan deze methode? Ja, in die zin dat TDD meer onderhoud vraagt naarmate de applicatie groeit. Bovendien kan het in eerste instantie behoorlijk lastig zijn om voor complexe materie een goede test te schrijven.

TDD: verschillende types testen

Afhankelijk van niveau en doel zijn er verschillende testen mogelijk:

Unit Level test de werking van een bepaalde klasse en wordt beschouwd als het laagste niveau
Integration Level controleert de werking van de applicatie met een externe service (bijvoorbeeld mailen of betalen)
Acceptance Level gaat na of de webapplicatie doet wat ervan verwacht wordt. Dat kan op twee manieren: enerzijds testen of het systeem zelf voldoet aan de verwachtingen (volledig losgekoppeld van de UI) en anderzijds de UI zelf. Bij de eerste manier wordt eerder getest op niveau van database en endpoints van API’s, bij de tweede op wat te zien is in de UI.

De structuur van een goede test

Een test binnen TDD volgt doorgaans een vaste structuur met drie fases:

De voorbereiding: het klaarzetten van de database met de nodige records – bij elke test wordt de database immers gereset. In deze fase kunnen ook enkele klassen binnen de applicatie vervangen worden door ‘test doubles’ (een eigen instantie die het gedrag van een klasse nabootst) om hier dan in fase 3 assumpties rond te maken.
Acties: van het bezoeken van een endpoint van de applicatie of van een service tot het aanspreken van een methode van een klasse
Evaluatie: het stellen van enkele assumpties op de ondernomen acties: bepaalde responses, of wijzigingen in de database. Slagen alle assumpties, dan slaagt de test.

Tips voor tests

Zelf een test schrijven? Zorg er dan voor zo expressief mogelijke namen, zodat je beter begrijpt wat de test eigenlijk moet testen. Neem ook de tijd om je testen bij te werken, zodat die steeds een optimale weergave zijn van de interne werking van de applicatie. Wat je ook kan doen, is test-doubles van een externe service schrijven om niet afhankelijk te zijn van de service en mogelijk internetverbinding. Dit versnelt bovendien je test suite en zorgt ervoor dat je zelfs offline al je testen kan gebruiken. Gebruik verder alleen een externe testbibliotheek als dat nodig is – kleine helpers schrijven kan vaak al voldoende zijn.

Meer informatie en tips rond TDD? Hier en hier vind je alvast enkele nuttig video’s.