soemirno

Ben weer in een coachende rol terecht gekomen en het leek me zinvol om terug te kijken op hoe ik op mijn manier van werken ben gekomen. Ik begin met mijn belangrijkste stokpaardje: Test Driven Development.

In 2001 ben ik begonnen met het schrijven van unit testen voor mijn code. Bij het coderen bedacht ik van tevoren eerst wel de klassen/modules en methodes, maar ging bij het implementeren ervan eerst de testen voor schrijven. Het test first was dus op methode nivo. Het belangrijkste effect was dat ik precies wist wanneer ik klaar was. Voorheen was er toch altijd het knagend gevoel dat je iets vergeten was, of dat je te lang door ging met de code terwijl het al af was.

Een ander gunstig side effect kwam door de beperking van de testframeworks: het moeilijk kunnen testen van de GUI en de database. De gui omdat het vrij lastig is om deze aan te sturen, de database omdat ik met de steeds wijzigende inhoud van de database zat. Om toch zoveel mogelijk code te kunnen testen scheidde ik automatisch mijn gui en database code van mijn midden laag.

De volgende stap was het leren werken met mock's. In eerste instantie gebruikte ik de mockframeworks als stub voor de database in testen, maar gaandeweg leerde ik dat het bij mock testing om het valideren van gedrag gaat. Het kan best lang duren voordat je dit goed snapt, omdat je best wel veel tijd kwijt kan zijn aan het maken van je mock testen. De testen vergen veel boilerplate code in java, je kunt alleen mocken van een interface, en het resultaat vind ik erg slecht leesbaar.

De stap van mock testing naar Behaviour Driven Development is erg klein. Het rspec framework maakt effectief gebruik van de engelse taal om in de juiste termen te denken. Het ingebouwde mock framework vergt dankzij ruby minder boilerplate code en de examples zijn beter leesbaar hierdoor. Toch maakte ik bij rspec eerst nog de fout om vooral de state van de objecten na een actie te controleren en niet zozeer naar het gedrag van de objecten te kijken.

Ik gebruik nu rspec meer als design tool om tot een ontwerp te komen en inzichten te verkrijgen. Ik ben dan meer bezig met de verantwoordelijkheden van objecten en interactie tussen objecten. Eigenlijk dus een beetje volgens de CRC card methode. Het heeft wel jaren geduurd voordat ik deze context switch heb kunnen maken en waarschijnlijk is het inzicht pas gekomen nadat ik smalltalk had geleerd.

Hoewel het totale leertraject jaren geduurd heeft en ik nog steeds bezig ben, was de eerste stap vrij snel gemaakt en kan ik mij daar geen grote leercurve herinneren. Ook geen discipline problemen, de directe feedback van de groene balk gaf me een 'rush' en dat was verslavend. Ik denk dat, dat ook de essentie is van het succesvol omarmen van TDD. Als je er niet dat fijne gevoel van krijgt kost het alleen maar energie. Dat is namelijk de enige verklaring die ik kan bedenken voor het feit dat zoveel programmeurs er nog moeite mee hebben. Ik zal daar rekening mee houden als ik het overbreng en focussen op de snelle feedback.