Naar inhoud springen

Test-driven development

Uit Wikipedia, de vrije encyclopedie
Dit is een oude versie van deze pagina, bewerkt door O0Rollo0o (overleg | bijdragen) op 4 mei 2010 om 08:02. (→Bronnen)
Deze versie kan sterk verschillen van de huidige versie van deze pagina.

Test-Driven Development (TDD) is een ontwikkelmethode voor software waarbij eerst tests worden geschreven en daarna pas de code.[1] Deze methode kan goed gecombineerd worden met eXtreme Programming (XP), aangezien XP ook gebruikt maakt van korte ontwikkelcycli met continu testen van de software.

De naam Test-Driven Development komt van Kent Beck, die deze techniek in 2003 op papier heeft gezet en daardoor de bekendheid ervan verbeterd heeft.

Ontwikkelcyclus

De ontwikkelcyclus hieronder is gebaseerd op het boek Test-driven development by example[2] van Kent Beck. Deze cyclus kan zo vaak herhaald worden als nodig is om de code volledig werkend te krijgen volgens de requirements.

  1. Test maken: In Test-Driven Development wordt altijd voorafgaand aan het schrijven van de code, een test gemaakt die gebaseerd is op een requirement. Deze test zal initieel waarschijnlijk falen, aangezien het stuk code waarop deze test van toepassing is nog niet is geschreven.
  2. Alle tests draaien en kijken of de nieuwe test faalt: Het laten falen van de nieuwe test is ervoor om te kijken of de requirement niet toevallig al is geïmplementeerd, of dat de test fouten bevat.
  3. Code schrijven: In deze stap wordt de daadwerkelijke code geschreven om de zojuist gemaakte test te laten slagen. Deze code mag alleen functionaliteit bevatten die nodig is om de test te laten slagen.De code hoeft niet perfect geschreven te zijn, zolang deze maar werkt. In een latere stap zal de code nog herschreven worden volgens de standaard.
  4. Tests draaien en kijken of deze slagen: In deze stap worden alle tests nogmaals gedraaid en wordt gekeken of alle tests slagen. Is dit het geval dan is dit een goed uitgangspunt om aan de volgende stap te beginnen.
  5. Code herschrijven: In deze stap wordt de code opgeschoond en volgens de standaard herschreven. Ook zal eventuele dubbele code, die makkelijk was om de test te laten slagen, verwijderd worden.

Voordelen

  • Er wordt bij Test-Driven Development gekeken vanuit het perspectief van de gebruiker. De testcases waarvoor de code wordt geschreven zullen namelijk gebaseerd zijn op de requirements, die vanuit het oogpunt van de gebruiker zijn opgesteld. Problemen met de bruikbaarheid van de interface kunnen zo eerder worden gevonden en gecorrigeerd in een stadium waarin het gemakkelijkst is.[3]
  • Er wordt veel meer gelet op de requirements, aangezien de tests daarop gebaseerd zijn. Extra, wellicht overbodige, functionaliteiten zullen hierdoor niet geïmplementeerd worden, waardoor de codehoeveelheid voor het programma kleiner blijft.
  • Doordat alle code van het begin af aan wordt getest, wekt dit meer vertrouwen bij het ontwikkelteam, alsmede bij de klant.
  • Ondanks de extra code die nodig is voor het schrijven van de tests, zal de ontwikkelingstijd toch korter worden. Dit aangezien er minder tijd nodig is voor debuggen, omdat fouten vaak al in een vroeg stadium worden gevonden.
  • Aangezien alle onderdelen van de code los van elkaar geschreven zullen worden, met het doel één specifieke test te laten slagen, zullen deze onderdelen ook kleiner en meer gefocust zijn. Ook zullen ze een lossere koppeling met elkaar hebben.

Nadelen

  • Een voorwaarde voor een succesvol gebruik van deze testmethode is dat het hele team, alsmede het management, achter deze methode staat. Wanneer deze methode namelijk maar half geïmplementeerd wordt, zal hij nutteloos blijken en alleen maar tijdsverlies tot gevolg hebben.
  • Meestal is het zo dat de programmeur bij deze methode zowel de tests als de code voor de applicatie schrijft. Dit heeft tot gevolg dat wanneer de programmeur iets over het hoofd ziet, dit in zowel de test als de code over het hoofd gezien zal worden.
  • Wanneer er een groot aantal tests succesvol zijn, kan dit de indruk geven dat de applicatie volledig getest is. Een valkuil is dat een integratie- en systeemtest niet of nauwelijks uitgevoerd worden.

Toepassing

Voor het ontwikkelen/upgraden van toolkits, zoals bijvoorbeeld de Dojo Toolkit, is Test-Driven Development een toepasbare manier van development, aangezien integratie- en systeemtests hierbij nog niet terzake doen.

Referenties

  1. ↑ Hans van Vliet, Software Engineering: Principles and Practice, 3rd edition, Wiley, 2008, p. 421.
  2. ↑ Kent Beck, Test-Driven Development By Example, 2003
  3. ↑ Hibbs, Jewett & Sullivan, The Art of Lean Software Development, O'Reilly, 2009, p. 51
Overgenomen van "https://nl.wikipedia.org/w/index.php?title=Test-driven_development&oldid=21021868"