Ben weer even getriggered door wat sessies op J-Spring om wat aandacht te besteden aan modelleren. Ik doe al jaren TDD en intussen ook al veel met rspec en BDD en ik merk dat de kwaliteit van de code daardoor enorm is verbeterd, maar over de resulterende ontwerpen ben ik nog niet helemaal tevreden.
De reden blijkt dat ik me nog steeds laat leiden door de infrastructuur, want uiteindelijk moet de code ook op een platform draaien en moet ik gebruik maken van beschikbare libraries. Maar dat is dus geen excuus. Zowel Rob Vens, als Marc Evers en Rob Westgeest, gaven aan dat je je best wel kan focussen op het probleem domein en dat je benodigde infrastructuur via wrappers of adapters van je domein kunt scheiden.
Een tweede is dat ik me nog steeds focus op het statische model en niet op gedrag. Zowel in rspec als Junit, gebruik ik wel mock's om gedrag te controleren, maar dat doe ik meestal als ik er niet uitkom met gewone asserts, of als deze te duur zijn. Bijvoorbeeld bij communicatie met externe systemen en/of database requests.
Met rspec ben ik nu aan het proberen om de sessie's in de praktijk te brengen. Juist doordat je zo goed kunt uitdrukken in gewone taal, lijkt het me makkelijker dan de jmock manier.
Met een CRC card als basis gaat het vrij simpel. De responsibilities kun je zo opschrijven in je spec's met "it should" en van je collaboraters maak je mock's. Daarna kun je verwachte interacties tussen je class en zijn collobaraters definieren.
Je kunt je class dan implementeren ook al bestaat de rest van je systeem nog niet. In ruby of een andere dynamische taal dan. Met java zul je toch eerst interfaces naar je collaboraters moeten maken, anders compileert het gewoon niet.
Ik merk dat mijn classes, zich nu net wat anders beginnen te ontwikkelen, maar ik heb nog geen complete applicatie op deze manier gebouwd om het resultaat goed te beoordelen.
