ORDINA BLOGT

Test Driven Development

Test Driven Development (TDD) is momenteel in opkomst. Is het een toegevoegde waarde? Een hype? Of misschien toch oude wijn in nieuwe zakken?

  • Kaspar van Dam
  • 9 december 2013

Onlangs heb ik samen met een collega een zeer enerverende workshop mogen geven aan een tweetal teams bij een klant  die recent begonnen is met Agile werken en SCRUM en die zoekende zijn wat zij nog meer kunnen doen om efficienter te werken als een team. Ordina was daarom gevraagd deze teams te vertellen over TDD en hen te inspireren deze nieuwe werkwijze toe te gaan passen in de dagelijkse praktijk als zou blijken dat dit van toegevoegde waarde voor hen zou kunnen zijn. Het was een bijzonder nuttige sessie waarbij we betreffende teams hebben weten te enthousiasmeren, maar tevens een goede manier om zelf ook nog eens kritisch na te denken over Test Driven Development. En vandaar de vraag: is TDD van toegevoegde waarde? Een hype? Of oude wijn in nieuwe zakken?

Wat is TDD?

Laat ik beginnen met het geven van een definitie van TDD zoals wij dit binnen Ordina zien. Test Driven Development is volgens de theorie een ontwikkelmethode waarbij de unittests/bouwtests gemaakt worden voordat men gaat ontwikkelen. Wij zien dit binnen Ordina echter als een meeromvattende methodiek. Het gaat om testen in het algemeen voordat er ontwikkeld wordt (in de literatuur ook wel omschreven als Acceptation Test Driven Development). Men begint tijdens het maken van een functioneel ontwerp ook reeds met het maken van functionele testen. Parallel daaraan maakt de ontwikkelaar zijn bouwtesten en ontstaat een nauwe samenwerking tussen bouwer en tester om de diverse testen op elkaar aan te laten sluiten en onnodig dubbel werk te voorkomen.

 

In principe begint de bouwcyclus vervolgens met het initieel uitvoeren van de test met de verwachting dat deze faalt: hetgeen getest wordt is immers nog niet gebouwd! Theoretisch gezien kan de test uiteraard ook succesvol zijn waaruit dan blijkt dat de functionaliteit reeds bestaat. Er hoeft dan niets gebouwd te worden. Indien een test faalt gaat men iteratief bouwen en hertesten net zo lang tot het punt bereikt wordt waarop de test succesvol is. Dit principe geldt zowel voor de functionele acceptatie testen als de bouwtesten.

Nieuw, of "New and Improved"?

Is dit principe van testen voor bouwen nu een nieuw verschijnsel? Wanneer gekeken wordt naar de geschiedenis van de software ontwikkeling en het software testen niet:

In feite is software ontwikkeling begonnen met het uitvoeren van testen en ontdekken dat de computer iets niet kon dat men wel graag wou. Men ging vervolgens aan de slag om deze nieuwe functionaliteit werkend te krijgen. In de jaren 80 wordt er reeds melding gemaakt van de methodiek "Test, then Code". Pas in 2002 komt Beck met de term Test Driven Development (TDD). Maar in feite is dit niet meer dan een term en een verzameling handvatten voor een goede aanpak. Ofwel, er is sprake van nieuwe wijn in oude zakken! Maar betekent dit automatisch dat deze manier van werken geen toegevoegde waarde heeft? In mijn optiek geeft het feit dat deze werkvorm al bestaat sinds het begin van de software ontwikkeling juist aan dat het een bijzonder waardevolle werkwijze is. En het feit dat Test Driven Development hier handen en voeten aan geeft binnen de hedendaagse methodieken als Agile, Kanban of SCRUM voefgt hier enkel meerwaarde aan toe.

De toekomst van TDD

Ik geloof persoonlijk dan ook niet dat TDD slechts een hype is. Het bestaat al zeer lang en heeft reeds uitgebreid aangetoond van toegevoegde waarde te zijn. De huidige snelle opmars van deze methodiek is niet het gevolg van een hype, maar een gevolg van de gelijktijdige opkomst van diverse Agile werkwijzen. Test Driven Development sluit bij uitstek aan op de Agile werkwijze en kan in basis gezien worden als een overtreffende trap daarvan. De Agile methodieken en TDD vullen elkaar perfect aan.

Tijdens de workshop die wij onlangs gegeven hebben zagen de deelnemers dit ook duidelijk in. Zij waren daarom bijzonder enthousiast over deze nieuwe werkwijze en stellig van plan tijdens de eerstvolgende sprint reeds stappen te zetten om er daadwerkelijk mee aan de slag te gaan! Een mooie uitkomst van een geslaagde workshop. Ook belang bij deze workshop? Neem dan contact met me op of kaart het aan bij (jo)uw Ordina contactpersoon!

Over de auteur:

Kaspar van Dam

Kaspar van Dam is test(automatisering) consultant bij Ordina en adviseert collega's en klanten over vraagstukken rondom de thema's agile testing, behavior driven development (BDD), testautomatisering en meer.