Dit is een review van het boek: Growing object-oriented software guided by tests geschreven door Nat pryce en Steve Freeman. Een aantal maanden geleden heb ik al een eerste blog geschreven over een klein detail van dit boek. Voordat ik het boek ging lezen had ik al enige kennis van TDD, maar deze kennis wilde ik graag uitbreiden.

Het boek

Het boek beschijft een manier om met behulp van TDD OO software te ontwikkelen. Binnen het boek wordt hevig gebruik gemaakt van Mock objecten om de ondeliggende code te testen. Ook wordt er gebruik gemaakt van geautomatiseerde acceptance tests. Deze variant van TDD die ook wel de “London school” wordt genoemd is (mede) bedacht door de schrijvers van het boek.

Het boek heeft 5 delen. Deel 1 is een introductie van TDD is en waarom het te gebruiken. Deel 2 beschrijft het TDD proces dat gebruikt wordt in detail. Deel 3 is een groot voorbeeld waar de theorie in de praktijk wordt gebracht. Deel 4 legt uit hoe je kunt zorgen dat je tests onderhoudbaar worden/blijven en tot slot behandelt deel 5 nog een aantal advanced topics.

Deel 1 en 2

Door het lezen van deel 1 en 2 krijg je een goed idee hoe het proces wordt aangepakt als je deze methodiek volgt. Belangrijke concepten:

• Walking skeleton
• Acceptance tests
• Tell don’t ask
• Listening to the tests

Het laatste hoofdstuk van deel 2 is interessant omdat daar een aantal redenen wordt gegeven om nieuwe objecten en value types te introduceren. Waarschijnlijk zijn deze wel bekend, maar de opsomming zorgt voor extra houvast.

Redenen om value types te introduceren:

• breaking out: te complex object vraagt om opsplitsing
• budding off: een nieuw type om een Domain concept te vangen. Kan slechts 1 field zijn of zelfs geen enkel.
• bundling up: als het vaak voorkomt dat we een aantal variabelen samen gebruiken kan het nuttig zijn om ze samen te voegen in een nieuw type.

Objecten ontstaan als:

• breaking out: opsplitsen van te complex object.
• budding off: nieuwe functionaliteit past niet in het huidige object en vraagt om een nieuwe class.
• bundling up: als 2 objecten samen werken is het misschien nodig om de objecten in een nieuwe class te bundelen. The composite is simpler than the sum of his parts.

Deel 3

Na het lezen van deel 1 en 2 dacht ik dat ik de materie begreep. Dit bleek echter niet het geval. In deel 3 wordt een voorbeeld uitgewerkt. Dit is in dit geval een “Auction sniper”. Deze auction sniper kan op veilingen bieden tot dat een (ingegeven) maximum bedrag is bereikt. De GUI laat de status van de huidige veilingen zien.

In het voorbeeld wordt er stap voor stap gewerkt naar een volledige applicatie. De schrijvers leggen ook uit waarom ze voor welke stap kiezen. Gedurende Stap voor stap ontstaat een beter design van de applicatie door te luisteren naar de “test smells”. Door het voorbeeld werd mijn inzicht in OO-design in ieder geval vergroot. En ik denk dat TDD helpt bij het verkrijgen van een betere architectuur. (Zie ook mijn eerdere blog hierover.)

Deel 4 en Deel 5

Deel 4 beschrijft hoe slecht design van je applicatie zichtbaar wordt en hoe je jouw (unit)tests onderhoudbaar kan houden. Deel 5 legt uit hoe je persistence frameworks, threaded applicaties en asynchrone code kunt testen.

Conclusie

Als je nog niet ervaren bent in TDD/OO en je wilt meer inzicht verkrijgen is dit een zeer nuttig en praktisch boek om dit te leren. Het is helder en duidelijk geschreven en het voorbeeld geeft groot inzicht. Gedurende het lezen was ik wel af en toe de structuur kwijt van het voorbeeld. Terugbladeren en de schema’s bekijken in het vorige hoofdstuk hielp dan enorm. Graag had ik de schema’s wat vaker zien terugkomen. Het kan er echter ook aan liggen dat ik het boek gedurende een aantal maanden gelezen heb. Als dat binnen een kortere tijdsperiode gedaan wordt verwacht ik dat terugbladeren minder nodig is.

P.S.
Sommigen denken dat je moet kiezen tussen de London school en classic TDD. Jason Gorman heeft daar naar mijn idee een goed antwoord op gegeven. Hij stelt dat ze beide nodig zijn.