TDD is hard

Test-driven development is not really as easy as they say. Maybe nobody said it was easy, but I got that impression.

I’ve been trying to do TDD for about two years, and at first I thought it was horrible. Mostly because it forced me to break dependencies to the degree that my code was no longer nice and self-contained the way I used to like it.

Then I fell in love, or became infected, whichever you prefer. I realised that the dependency-breaking is a good thing, and that it’s pretty incredible to have automated regression tests for all your code. I tried to test-drive everything, and valued testing in isolation higher than anything else.

Now I have come to the conclusion that I’m not very good at testing behavior. I tend to test every possible detail, control flow or error condition I can come up with, and this causes the tests to lock the code beyond modification.

I’m trying to find a middle ground where I lock down interesting behavior and choose units at the right level of detail to begin test-driving. Maybe then I can get the extra boon of having the tests tell me more about what I need to build, rather than just making it more difficult to change existing code.

I think it comes down to experience in OO design. I doubt a beginner using TDD will automatically produce better designs than a more experienced developer who is not test-driving.

This just goes to show what I’ve suspected for a while: agile practices are generally very well distilled best practices, but they do require significant prior experience on behalf of their users to be beneficial.

Or maybe I’m just a slow learner.



Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in: Logo

Du kommenterar med ditt Logga ut / Ändra )


Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )


Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )


Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s