IS TDD wel mogelijk zonder ontwerp vooraf?

[ocf81]

Tijdens het programmeren probeer ik vaak TDD toe te passen. Ik loop echter steeds tegen het volgende aan:

Wanneer ik een test definieer heb ik voor een functie een bepaalde interface in gedachten. Maar tijdens het uitwerken van die functie komt het nogal vaak voor dat ik de signature verander. Hierdoor zijn mijn tests niet meer geldig en moeten ze herschreven worden. Soms verandert zelfs de opzet van een class of een package door voortschrijdend inzicht. (bijvoorbeeld besluiten toch een ander design pattern toe te passen omdat het bij nader inzien beter past bij de situatie)

Nu vraag ik mij af waar de lijn tussen TDD en achteraf testen ligt. Wanneer men de test na het maken van de methode moet aanpassen is het strict genomen geen TDD meer. Is het eigenlijk niet beter om vooraf een groot, min of meer allesomvattend, ontwerp te maken waardoor er meer denktijd in de interface gestopt kan worden voordat deze in code wordt uitgewerkt?(BDUF)

[Grijze Vos]

Disclaimer: ik ben geen TDD goeroe.

Je hoeft natuurlijk niet al je tests te schrijven voordat je gaat developen.
Als je nou eerst een globale opzet maakt.

Dan per functie:
* uitwerken specificatie
* tests schrijven
* implementeren.

Op die manier zou jouw probleem voorkomen bij het kopje "uitwerken specificatie", en niet bij het kopje "implementeren".

[Keeper]

Hoe schrijf je dan nu tests? Als je heel strict TDD wilt aanhouden heb je namelijk de volgende workflow.

* Schrijf een test die faalt
* Schrijf het minimale nodig om de test te laten slagen
* Refactor

Dat impliceert dat je dus per method bezig bent met het schrijven van tests en het implementeren. Tijdens het schrijven van je tests/implementatie kan je dan ontdekken dat je andere functionaliteit nodig hebt. Deze kan je dan aan je todo-list toevoegen en bouwen op het moment dat je klaar bent met het implementeren van de eerste functie.

In principe zou de manier waarop je een functie implementeert niet moeten uitmaken voor je tests. Schrijf je dan misschien niet tests die al te specifiek op de implementatie ingaan waar dat niet hoeft?

[ocf81]

Meestal heb ik een aantal classes die ik al heb bedacht bij het bestuderen van het probleem en dan vul ik het gedrag van die classes in door voor elk gedrag een methode op te stellen. Momenteel schrijf ik (unit)tests door eerst te bedenken op welke manieren het beoogde gedrag risico's bevat, waarna ik daarop de testcases opstel. Daarna vul ik de testcases, meestal door de te testen methode te voeren met (het liefst mocked) data en dan controleer ik het resultaat middels assertions.

Daarna schrijf ik de methode, maar dan kom ik vaak dus het in de OP beschreven fenomeen tegen.

Als alles werkt en de specs klaar zijn schoon ik de code op zodat het minder rommelig is.

Het punt is niet dat ik niet met een testframework kan omgaan ofzo, het zit hem in de manier van werken.

[Dricus]

Ook ik ben geen TDD goeroe. Ik ben me sinds een jaar terug wel steeds meer in TDD gaan verdiepen en probeer er door oefening beter in te worden. Een lastig ding vind ik te bepalen hoeveel design je vooraf moet doen voordat je begin met programmeren. Het definitieve antwoord heb ik nog niet gevonden.

Deze presentatie is een uitwerking van de Bowling Game kata (kata = TDD oefening). In deze uitwerking wordt goed duidelijk dat je met (teveel) design vooraf het gevaar loopt van overengineering. De kracht van TDD is IMO nu juist dat je door het bijbehorende YAGNI principe kunt voorkomen dat je een te lomp programma schrijft voor je probleem.

Mijn voorlopige conclusie tot nu toe is dat ik me bij wat grotere programma's vooraf probeer te beperken tot het definiëren van de "architectuur" van het programma. In de praktijk komt dat erop neer dat ik probeer te bepalen welke patterns ik nodig denk te hebben. Bijvoorbeeld MVC voor GUI en Dependency Injection voor het backend gedeelte. Ik probeer ook te bepalen welke classes ik nodig ga hebben, maar ga dan niet verder dan het benoemen van die classes. De benodigde methods ontstaan tijdens het TDD proces.

Edit:
Aanvullende voorlopige conclusie: Hoe gedetailleerder het ontwerp vooraf, hoe minder design-level voordeel je gaat hebben met een TDD aanpak. Waar precies de grens ligt, en of die grens überhaupt eenduidig te definiëren is, is mij echter nog niet duidelijk.

[ Voor 9% gewijzigd door Dricus op 17-07-2012 21:53 ]

[whoami]

TDD laat je net toe om je API / class-interface te gaan bepalen door het schrijven van een test. Je kan wel al nadenken over hoe je die class lib best gaat gaan gebruiken, maar, het is net door het schrijven van eerst een test, dat je op een 'organische' manier je api gaat gaan definieren. Daar (in je test) ga je nl. voor de eerste keer je class gaan gebruiken, en, doordat die class er nog niet is, ga je als vanzelf code gaan schrijven zoals je die class wilt gaan gebruiken.

TDD gaat niet zozeer (of toch niet enkel) over het testen an-sich. Het gaat net over het 'nadenken over je API' en het ontwerpen daarvan. De test die je dan hebt, is natuurlijk een bonus.

Ik hoop dat ik me hier een beetje duidelijk heb gemaakt.

kata (kata = TDD oefening)

Kata is een term die o.m. uit de Karate stamt. Het is een reeks van vastgelegde, opeenvolgende bewegingen / oefeningen, waardoor een soort van automatisme wordt aangeleerd.

[ Voor 27% gewijzigd door whoami op 17-07-2012 23:10 ]