Wat is Test-Driven Development (TDD)?

large__8282043567Testgedreven ontwikkeling is een proces dat berust op de herhaling van een zeer korte ontwikkelingscyclus. Het is gebaseerd op het test-first concept van Extreme Programming (XP) dat eenvoudig ontwerp met een hoog niveau van vertrouwen aanmoedigt.

de procedure voor het doen van TDD volgt:

  1. Schrijf een test
  2. alle tests uitvoeren
  3. implementatiecode
  4. alle tests uitvoeren
  5. Refactor

deze procedure wordt vaak Rood-Groen-Refactor genoemd.

tijdens het schrijven van tests zijn we in de rode staat. Aangezien de test is geschreven voor de daadwerkelijke implementatie, wordt het verondersteld te mislukken. Zo niet, dan is de test verkeerd. Het beschrijft iets dat al bestaat of verkeerd is geschreven. Groen zijn tijdens het schrijven van tests is een teken van vals positief. Zulke Tests moeten worden verwijderd of opnieuw worden uitgevoerd.

vervolgens komt de groene staat. Wanneer de uitvoering van de laatste test is voltooid, moeten alle tests slagen. Als ze dat niet doen, is de implementatie verkeerd en moet worden gecorrigeerd.

het idee is niet om de implementatie definitief te maken, maar om net genoeg code te geven om tests te doorstaan. Als alles groen is, kunnen we de bestaande code heractiveren. Dat betekent dat we de code optimaler maken zonder nieuwe functies te introduceren. Terwijl refactoring op zijn plaats is, moeten alle tests de hele tijd passeren. Als een van hen faalt, brak refactor een bestaande functionaliteit. Refactoring mag geen nieuwe tests omvatten.

snelheid is de sleutel

large_5836417589
ik heb de neiging om TDD te zien als een spelletje pingpong (of tafeltennis). Het spel is erg snel. Hetzelfde geldt voor TDD. Ik heb de neiging om niet meer dan een minuut te besteden aan weerszijden van de tabel (test en implementatie). Schrijf een korte test en voer het uit( ping), schrijf de implementatie en voer alle tests uit (pong), Schrijf een andere test (ping), schrijf de implementatie van die test (pong), refactor en bevestig dat alle tests passeren (score), herhaal. Ping, pong, ping, pong, ping, pong, score, opnieuw serveren. Probeer niet om de perfecte code te maken. Probeer in plaats daarvan de bal te laten rollen totdat je denkt dat de tijd rijp is om te scoren (refactor).

het gaat niet om het testen van

T in TDD wordt vaak verkeerd begrepen. TDD is de manier waarop we het ontwerp benaderen. Het is de manier om ons te dwingen om na te denken over de implementatie voordat het schrijven van de code. Het is de manier om de code beter te structureren. Dat betekent niet dat tests die voortvloeien uit het gebruik van TDD nutteloos zijn. Verre van dat. Ze zijn erg nuttig en stellen ons in staat om met grote snelheid te ontwikkelen zonder bang te zijn dat er iets kapot gaat. Dat geldt vooral wanneer refactoring plaatsvindt. In staat zijn om de code te reorganiseren, terwijl het vertrouwen dat er geen functionaliteit wordt gebroken is een enorme boost aan de kwaliteit van de code.

het hoofddoel van TDD is het ontwerpen van codes met tests als zeer nuttig nevenproduct.

Spot

om snel te kunnen testen en zo constante feedback te kunnen geven, moet code zo worden georganiseerd dat methoden, functies en klassen gemakkelijk kunnen worden bespot en gestoten. Snelheid van de uitvoering zal ernstig worden beïnvloed, bijvoorbeeld, onze tests moeten communiceren met de database. Door externe afhankelijkheden te bespotten zijn we in staat om die snelheid drastisch te verhogen. Gehele unit tests suite uitvoering moet worden gemeten in minuten, zo niet Seconden. Belangrijker dan snelheid, het ontwerpen van de code op een manier die gemakkelijk kan worden bespot en gestoten dwingt ons om die code beter te structureren door het toepassen van scheiding van zorgen. Met of zonder spot, de code moet worden geschreven op een manier dat we, bijvoorbeeld, gemakkelijk de ene database te vervangen door een andere. Dat “een ander” kan worden, bijvoorbeeld, bespot of in-memory database.

een voorbeeld van spot in Scala is te vinden in het Scala Test-Driven Development (TDD): Unit Testing File Operations with Specs2 and Mockito article. Als uw programmeertaal van keuze is niet Scala, artikel kan nog steeds zeer nuttig zijn om het patroon dat kan worden toegepast op elke taal te zien.

Watchers

zeer nuttig hulpmiddel bij het werken op de TDD-manier zijn watchers. Het zijn frameworks of tools die worden uitgevoerd voordat we beginnen te werken en zijn op zoek naar een verandering in de code. Wanneer een dergelijke verandering wordt gedetecteerd, worden alle tests uitgevoerd. In het geval van JavaScript staan bijna alle bouwsystemen en taakrunners dit toe. Gulp (mijn favoriet) en Grunt zijn twee van de vele voorbeelden. Scala heeft onder andere een SBT-revolver. De meeste andere programmeertalen hebben vergelijkbare tools die (indien nodig) opnieuw compileren en alle (of getroffen) tests uitvoeren wanneer de code verandert. Ik heb altijd mijn scherm gesplitst in twee vensters. De ene met de code waar ik aan werk en de andere met resultaten van tests die continu worden uitgevoerd. Het enige wat ik moet doen is erop letten dat de output van die watchers overeenkomt met de fase waarin ik ben (rood of groen).

documentatie

een andere zeer nuttige bijwerking van TDD (en goed gestructureerde tests in het algemeen) is documentatie. In de meeste gevallen is het veel gemakkelijker om uit te vinden wat de code doet door te kijken naar tests dan de implementatie zelf. Bijkomend voordeel dat andere soorten documentatie niet kunnen bieden is dat tests nooit verouderd zijn. Als er een discrepantie is tussen tests en de implementatiecode, falen de tests. Mislukte tests betekenen onjuiste documentatie.

Tests als documentatie artikel geeft een wat diepere redenering achter het gebruik van tests in plaats van traditionele documentatie.

samenvatting

in mijn ervaring is TDD waarschijnlijk de belangrijkste tool die we in onze software toolbox hebben. Het kost veel tijd en geduld om bedreven te worden in TDD, maar als die kunst eenmaal onder de knie is, neemt de productiviteit en kwaliteit drastisch toe. De beste manier om TDD te leren en te oefenen is in combinatie met pair programming. Net als in een spel ping pong dat twee deelnemers vereist, kan TDD in paren zijn waar de ene coder tests schrijft en de andere de implementatie van die tests schrijft. Rollen kunnen schakelen na elke test (zoals het vaak wordt gedaan in het coderen dojos).

probeer het eens en geef niet op wanneer u geconfronteerd wordt met obstakels, aangezien er veel zullen zijn.

Test Driven Development (TDD): Best Practices met behulp van Java voorbeelden is een goed uitgangspunt. Ook al maakt het gebruik van Java voorbeelden, dezelfde, zo niet alle, praktijken kunnen worden toegepast op elke programmeertaal. Voor een voorbeeld in Java (zoals in het vorige geval, het is gemakkelijk toepasbaar voor andere talen) neem een kijkje op TDD voorbeeld Walkthrough artikel.

een andere geweldige manier naar perfectie TDD vaardigheden zijn code katas (er zijn er veel op deze site).

Wat is uw ervaring met TDD? Er zijn net zoveel variaties als er teams oefenen en ik zou graag horen over uw ervaring.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.