I’m currently putting together a mini project in order to get a better understanding of some technologies & methodologies that I haven’t used before, here are my thoughts so far:
It took a while to get into the right mindset from the usual “What classes will i need to build? and how will they be used?” to the TDD way of thinking “What do I want the classes to do for me in order to pass this test?” Also without having a fancy IDE plugin such as R# to perform code generation it took a bit longer to go from writing a test to creating interfaces to get the tests compiling.
Using a mocking framework seems to be the way to go if you want to perform TDD I can’t even imagine how much extra time it would take to hand roll a load of static mock objects!
Overall so far I’m liking the process of writing tests first then writing the code to make the test pass it has lead to a clean API and has made performing any refactoring a lot less painful although the latter is more to do with performing unit tests in general.
I first came across this technique while watching a screencast on dnrTV from Jean-Paul Boodhoo whereby each object is derived from an interface, I think this technique ensures that objects are loosely coupled (definitely a good thing) which allows dependency injection to take place and therefore makes mocking of objects easy. There will be cases were deriving an object from a interface would be overkill possibly if the object was used for passing data and did not perform any behaviour such as a DTO object, having a public property getter/setter on the interface and the object doesn’t really give any benefit. But overall I think the technique is very useful especially on service layer/data access layer objects.
Till now whenever I have performed any unit testing I have always built a static mock object that implements abstract behaviour in a consistent way. When I first got hold of rhino mocks and tried using it I got very frustrated! It definitely isn’t a framework that can referenced and picked up as you go along (unless maybe you have used another mocking framework before), I was on the verge of not bothering and finding another mocking framework to use but I found a really good tutorial from aspalliance part 1 & part 2 these tutorials saved me from myself 🙂 Now I have got the hang of using it I find it invaluable and kudos for Ayende for creating it and maintaining it so well!
To be honest I have cheated a little here as I was abiding to these principle’s from the start, it was only part of the way in when it hit me, my problem was that I was trying to do much this was done by writing extra code while trying to make a test pass, instead of making sure the test passed I got drawn into trying to adding extra features and guessing how a certain object may be used (this closely fits with the difference in mindset you need when performing TDD).
I have now learnt my lesson that the highest priority should be making the unit test pass using the most simple way, then to perform refactoring if needed running the tests at stages to make sure we haven’t broken anything, and if we need the extra features at a later point then they should be driven out unit test first.