Workshop Test-driven development

Afgelopen woensdag hadden we bij Luminis Arnhem weer een pizzasessie. Dit keer kwamen we bijeen om te experimenteren met TDD, oftewel Test-Driven Development. TDD is een softwareontwikkelmethode waarbij eerst tests worden geschreven en daarna pas de functionaliteit. Het doel van de avond was om deze manier van ontwikkelen extra onder de aandacht te brengen. En om hiermee te ervaring op te doen zonder druk van een project waar je dagelijks mee bezig bent.

De avond was ruwweg in twee delen opgesplitst. Tijdens het eerste deel werd uitgelegd wat TDD inhoudt en ging iedereen zelf hardcore TDD-en. In het tweede gedeelte werd er een app vol met bugs voorgeschoteld en moesten de deelnemers deze er test-driven uithalen.

Deel 1 – test-first development

TDD schrijft voor dat er eerst een unit test wordt geschreven en daarna pas pas de functionaliteit. Echter is dat pas het topje van de ijsberg. De drie wetten der TDD zijn:

  1. Voordat je productiecode schrijft, moet je altijd eerst een falende unit test schrijven.
  2. Deze test bevat het meest minimale dat genoeg is om te falen, niet kunnen compileren is ook falen.
  3. Je moet het meest minimale schrijven aan productiecode dat genoeg is om alle falende tests weer te laten slagen.

Wanneer aan deze drie wetten gehouden wordt zal er steeds in een cyclus gewerkt worden. De testen en productiecode worden samen geschreven in 1 cyclus. Waarbij de testen maar een paar seconden eerder worden geschreven dan de productiecode. “Maar als we ons zo strikt aan deze regels houden, dan wordt onze code toch een rommeltje?” hoor ik je denken. Dat kan! En om dat te voorkomen moet je regelmatig je code weer netjes maken en herstructureren (refactoren). Omdat een dergelijke actie geen nieuwe productiecode zal opleveren valt dit buiten deze drie wetten. Dus voor stap 1 of na stap 3 mag je naar hartenlust refactoren. Zolang de tests maar blijven slagen. Dit noemen we de red/green/refactor cyclus.

De cyclus die je doorloopt bestaat dus telkens uit de volgende drie stappen:

  1. Schrijf een unit test die faalt.
  2. Schrijf productiecode die deze test laten slagen.
  3. Ruim je zojuist gemaakte troep op.

Na een live coding demonstratie van Rachid ging iedereen hiermee zelf aan de slag. We hadden een aantal puzzels uitgewerkt die de deelnemers dan test-driven moesten uitwerken.

Na zo’n 3 kwartier kwam deel 1 ten einde. Het bleek nog best lastig te zijn om de eerste kleine falende tests te schrijven, die wel bijdragen aan wat er uiteindelijk bereikt moet worden. Daarnaast merkten sommigen weer dat het wel makkelijk is dat je elke keer (cyclus) maar over een klein stapje hoeft na te denken.

Deel 2 – test-first bugfixing

In deel 1 hebben we gezien dat de ontwikkelaar zowel de tests als de productiecode schrijft. Dit heeft tot gevolg dat wanneer de programmeur iets over het hoofd ziet, dit in zowel de test als in de code over het hoofd gezien zal worden. Verder kan het lastig zijn om altijd 100% volgens de TDD-methode te werken. Echter bij het oplossen van bugs is het extra belangrijk om dit test-driven te doen.

Björn gaf een voorbeeld waar het oplossen van bug 1, ongemerkt een nieuwe bug had opgeleverd. En na het oplossen van de nieuwe bug, was bug 1 er weer terug ingeslopen. Om dit te voorkomen zal je dus voordat een bug wordt opgelost, eerst een falende test moeten schrijven die de bug bewijst. Vervolgens hoef je alleen nog maar de testen slagend zien te krijgen.

Om wat hands-on ervaring hiermee te krijgen had Björn een programmaatje gemaakt dat wisselgeld uitrekent. Als invoer wordt een verschuldigd bedrag en een betaald bedrag opgegeven, en vervolgens wordt het wisselgeld op het scherm wordt getoond. Er zaten natuurlijk een aantal bugs in dit programmaatje. De deelnemers kregen de opdracht om deze bugs test-first op te lossen.

All hands on TDD

Toen iedereen hier een tijdje mee had gestoeid naderde het einde van de avond. Tijdens de evaluatie bespraken we nog welke eigenaardigheden er zoal in het programmaatje zaten. De details zal ik hier niet bespreken, want misschien wil je hier zelf nog wel mee aan de slag. De code staat op Github en de bug-meldingen staan in dit document.

Het was een geslaagde avond, op naar de volgende pizzasessie!

Tweet about this on TwitterShare on LinkedIn

Reacties

Het e-mailadres wordt niet gepubliceerd.

*