I’ve been working hard the last six months teaching my teammates about unit testing, code reviews, SOLID, SCRUM and anything else I think we can benefit from. I feel lucky – for the most part they are open minded and accept my ideas and try them without prejudice, working this way has enabled better code and work for both the team and myself.
Over the last months the team’s productivity has increased, the unit tests got a lot better and the code has improved dramatically. But not all is peachy – There is one methodology that I’m having only partial success in convincing my team that they should use – namely Test Driven Development (TDD).
While some of the team use TDD exclusively others still find it too hard and/or cumbersome to use on their daily tasks. I know they’ve tried, and failed using TDD for some of their tasks and now the only reason they keep on trying is because I insist they do it – without real benefits.
Why some fail while others succeed
I wanted to investigate why TDD worked great for some while completely missing the point for others – could it be that the tasks of the developers that used TDD were easier to test? perhaps the developers that didn’t manage to apply TDD worked more with complicated legacy code that was just harder to test?
After much investigation I came to the conclusion that to some extent the success or failure of TDD depends on how easy it is to write tests for that piece of code which is effected heavily from the amount of code existing before the change and how well it was previously tested. But that’s not the whole picture, when I look at the code written by the developers that found TDD to be “just too much work” I almost always see more than one assert which indicates that they might be trying to test too much –and if you write the tests before the code means that it’s a lot harder to do that when you’re actually planning on implementing a few features at once – not very TDD at all…
The TDD way
TDD is not about the tests – it’s about design:
By writing the test you actually create a form of specification (singular not plural!) and by making the test pass you satisfy the requirement. By this logic multiple asserts means (more often than not) that you’re implementing multiple requirements at the same time. Another issue with trying to write a test for multiple requirements is that the test tends to be much more complicated than a test that checks only one thing.
One final thought
Multiple asserts is not necessarily a bad things, there might be a valid reason to writing multiple asserts to test a single requirement.
I have a trick to check if a test maps to more than one requirement – ask the developer “what are you testing here”, if he uses “and” in the sentence i.e. “I make sure that the username is valid and an email is send” he might be testing too many things.
Related links:
TDD is more than just writing unit tests
Why TDD is good for testers
The day I understood TDD
Helper Code 
The best trick I have for catch that out (the bit in “one final thought”) is to look at the test name – if the behaviour has anything like “and” / “with” etc. then it's a sign that the test needs to be broken out.
I failed with TDD miserably on my last project. At one point, there was quite a lot of pressure for finishing an iteration. So, I kind of went straight into coding without writing tests first, telling myself I'll fix that later. Needless to say, I never fixed my failing tests, and I wrote just a few new ones. And in the end I've lost much more time with fixing regression bugs and manual testing.
Why did that happen? Because I'm usually starting with integration tests. Once I implement the feature, I should have added some unit tests as well. But since the system worked, I hurried to check it off and switch to the next task. As a result, when an integration test breaks, it's really hard to fix it, since you don't know the part that's not working. So, supporting integration tests without covering the same functionality with unit tests is quite expensive, and you're tempted to stop it all the time.
I see I have to write a blog post about it..
Ulu: Let me know when you write this post – I'd love to hear your thoughts on the subject
Well said. We posted on this earlier.
http://agilescout.com/agile-development-and-re-work-look-at-test-drive-development-tdd/