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 10 mei 2010 om 13:51. (grote aanpassing wikified etc)
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] 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, nodig om de onderlinge afhankelijkheid van de componenten te minimaliseren, 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 specifiek gelet op de requirements, aangezien de tests daarop gebaseerd zijn. Extra, wellicht overbodige, functionaliteiten zullen hierdoor niet geïmplementeerd worden, waardoor de hoeveelheid programmacode binnen de perken blijft.
  • Doordat alle code van het begin af aan wordt getest, wekt dit meer vertrouwen bij het ontwikkelteam en bij de klant.
  • Ondanks de extra code die nodig is voor het schrijven van de tests, zal de ontwikkelingstijd toch korter worden, aangezien fouten al in een zeer vroeg stadia gevonden zullen worden.
  • Aangezien alle onderdelen van de code los van elkaar getest worden is de onderlinge afhankelijkheid kleiner en daarom minder complex.

Nadelen

  • De schrijft programmeur bij deze methode zowel de tests als de code voor de applicatie. 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.
  • 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

Deze methode valt onder eXtreme Programming (XP), aangezien het gebruikt maakt van een korte ontwikkelcycli met het continu testen van de software. 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=21110860"