Van Test tot Kwaliteit: Test Driven Development of Behavior Driven Development in Softwareontwikkeling
Ontdek de kracht van Test Driven Development (TDD) en Behavior Driven Development (BDD) in softwareontwikkeling. Leer hoe deze benaderingen de kwaliteit van je code en softwareproducten kunnen verbeteren.
In mijn voorgaande blog, ‘Kwaliteitsvolle Software Opleveren’, had ik het al over het belang van testen als essentieel hulpmiddel om de kwaliteit van code te verbeteren. Maar hoe pak je dat nu net aan?
Voor veel developers is het schrijven van testen een taak die ze niet graag doen. Ze doen het omdat het moet. Bij The Beehive kijken we hier net iets anders naar. Testen zijn een hulpmiddel om zo snel mogelijk extra value op te kunnen leveren. Door te testen kan je immers garanderen dat de code die je oplevert ook echt doet wat je verwacht dat ze doet.
Natuurlijk gebeurt het wel eens dat we onszelf erop betrappen dat we eerst onze code schrijven om ze nadien pas te gaan testen, wat er op die momenten inderdaad voor kan zorgen dat het een hels werk is. Je hebt immers veel code geschreven om die nieuwe functionaliteit uit te werken, maar nu moet je al die code nog gaan controleren. Dit is echter niet de beste manier.
Wouter Bauweraerts
Wat is Test Driven Development (TDD)
Test Driven Development (TDD) werd in extreme programming (XP) initieel omschreven als “test first". Dat zegt eigenlijk grotendeels al hoe we bij TDD aan de slag gaan. Laat ons daar nu in iets meer detail naar kijken:
Bij TDD spreken we vaak van de red-green-refactor cyclus. We beginnen zoals XP het beschrijft met onze test. Vooraleer we een letter code geschreven hebben, gaan we dus al onze eerste test schrijven. Logischerwijs zou deze test moeten falen en dus rood kleuren. Bij het schrijven van deze test baseren we ons uiteraard op de requirements die we moeten implementeren. Als we onze falende test hebben, testcode die niet compileert valt ook onder een gefaalde test, kunnen we beginnen met het schrijven van productiecode. Hier schrijven we net genoeg code om onze test terug te laten slagen. Als onze test geslaagd is, kunnen we gaan bekijken of onze code een refactoring kan gebruiken, zodat we de kwaliteit van de code kunnen verbeteren zonder dat we de functionaliteit van de code gaan veranderen. Deze stappen blijven we nu herhalen tot we de hele functionaliteit hebben kunnen uitwerken.
Wat is Behavior Driven Development (BDD)
BDD gaat nog een stap verder dan TDD. Hier vertrekken we niet vanuit unit-testen, maar we vertrekken echt vanuit de uit te werken functionaliteit. Vooraleer we beginnen te werken aan de uit te werken functionaliteit, gieten we de acceptatiecriteria die in de story geformuleerd zijn in automatische testen. Deze testen kunnen geschreven worden met behulp van verschillende tools en frameworks, maar je kan ook al een goede basis leggen door integratietesten te voorzien die alle acceptatiecriteria aftesten. Hierdoor moet je niet noodzakelijk nieuwe libraries gaan toevoegen of nieuwe frameworks gaan bestuderen, maar je kan gewoon gebruik maken van de test-libraries die je al aan het gebruiken bent.
Voordelen van TDD en BDD
Het schrijven van testen heeft naast het garanderen van de werking van de code ook nog andere voorbeelden. Aangezien we kwaliteit willen opleveren, is echter de correcte werking van de code wel het belangrijkste.
Daarnaast kan TDD en BDD bijdragen aan een betere architectuur en structuur in je code. Door eerst je testen te beginnen schrijven, ben je verplicht om al na te beginnen denken over de structuur van je code. De tijd dat we alle code in een enkel bestand schreven is gelukkig al lang voorbij, dat zorgt er ook voor dat we onze code gemakkelijker in kleine blokken kunnen verdelen die apart getest kunnen worden. Vaak zie je developers worstelen met het schrijven van testen. Ze vloeken omdat er bepaalde stukken code bijna onmogelijk bereikt kunnen worden met automatische testen of dat de setup die hiervoor nodig is gigantisch ingewikkeld is. Dat is een alarmsignaal dat aangeeft dat er ergens iets niet goed zit in de structuur. Als je eerst je testen schrijft, heb je dit probleem niet. Je past de structuur van de code immers zo aan dat het helpt om je testen te laten slagen.
Het laatste voordeel dat voor mij belangrijk genoeg is om te vermelden, is dat je niet alleen op het moment dat je de functionaliteit uitwerkt weet dat ze werkt. Je hebt een blijvende controle over de correcte werking van de code, omdat je de testen geautomatiseerd kan laten uitvoeren in de CI/CD tools die je gebruikt. Hierdoor zie je het zeer snel als er toch iets kapotgaat door wijzigingen in bestaande code, refactorings of versie-upgrades.
Het toepassen van TDD en BDD zoals het beschreven is, vergt natuurlijk wel wat discipline. Iedere developer komt wel eens in de verleiding om toch snel die kleine bug, story,… op te lossen zonder er eerst een test voor te schrijven. Hieraan zijn echter altijd risico’s verbonden, doordat je misschien uiteindelijk zelfs vergeet bepaalde delen grondig genoeg te testen. In het begin lijkt dit misschien niet problematisch, maar een codebase kan zeer snel groeien. Als je dan te vaak toegeeft aan de verleiding om “binnendoor” recht naar de oplossing te gaan, kan deze binnendoor vaak een grote omweg worden. Hier zal je dan achteraf ongetwijfeld de gevolgen van moeten dragen, doordat er meer bugs naar boven komen of cruciale delen ineens niet meer correct blijken te werken. Bijt even door de zure appel en pas je manier van werken aan, je zal er achteraf ongetwijfeld de vruchten van plukken. Code on!