How much TDD is enough TDD?
Posted by Kash Farooq on June 14, 2013
[We had a discussion at my current client about the right-level of TDD for a project under tight deadlines. This post is adapted from my contribution to that discussion]
I’ll start by stating that I am a huge fan of Test Driven Development.
I was introduced to TDD in 2005, “got it” straight away and now, 8 years later, would not want to program without it.
I’m not going to go into the benefits of TDD in this post. There are plenty of other blog posts out there that discuss that. Basically, as I said, I’m a fan – I’ve seen how easy it is to make changes to a well crafted TDD project and I would recommend TDD as a programming and design methodology to anyone that will listen.
However…would I aim for 100% code coverage on a project? I’m not sure. You have to be pragmatic. When you have project specific time constraints, you have to look at the value that each unit test is adding.
Consider a really light MVC controller action:
- Call a service.
- Use AutoMapper to map the response from a service contract to an identical view model.
- Return a View.
You may have dozens of controller actions like this. And for experienced developers, this three line method probably doesn’t need a unit test. There is no functionality to be described by the unit test. Your unit test is not adding any value. It is probably just going to replicate the implementation (and take more lines of code to do that replication). The test isn’t going to catch any accidentally introduced bugs as… well… it would be hard to introduce a bug without breaking it completely. And if you are changing a controller action, you’re going to hit it manually before you commit your change to source control, right?
Having said this, you also have to consider the skill and experience level of the team.
If I was mentoring someone new to TDD, or new to doing C# “properly”, I’d want them to do it 100% TDD. They shouldn’t write a line of production code without first writing the test. I would expect to see a unit test for that controller action example above.
But if your team is experienced, with developers who know how to do TDD, a test for the above method is probably overkill.
Forcing TDD on a novice developer has other benefits – it’s not just about teaching them how to do TDD. It forces developers to keep their classes small and targeted. Experienced developers should know all about SOLID. They shouldn’t need TDD to force their code to be clean and their classes to be targeted. It should be second nature.
So, when should an experienced developer do TDD?
How about if your MVC controller action was a bit fatter:
- Call a service.
- Get some data from it and call another service with that data.
- Conditionally manipulate/merge the data into one view model.
- Return a view dependent on what the model looks like.
Now, ignoring that this controller action may be doing too much, you definitely need to do this work TDD. There is sufficient logic that could be buggy, or could become buggy. Also, if your controller started as a simple 3 liner, but is starting to do more – now you do need to add a test.
Other example situations:
- Is the code going to re-used? If so, do it TDD.
- Is there functionality that needs documenting? A unit test with a suitable name can describe what functionality is being implemented – it provides accurate documentation rather than comments or documents that seem to be out of date a few days after they were written. And, obviously, you have a unit test ensuring that the functionality is working.
So, the “do I need to do TDD” questions could be:
- Is there sufficient logic that I will need to write that could be buggy? Do you have an if statement, or a loop or some other logic?
- Is this code going to be re-used?
- Is this code an API?
- Is it not obvious what the code is doing?
- Do you want to explain some functionality, or business rule, to a developer that might be looking at this code in the future?
If the answer to any of these questions is “yes”, you probably need to write a test first.
If the answer is “no”, and your code is as simple as the controller action example I gave at the start…you probably don’t need a test. But: you should have some UI-based integration tests (e.g. using something like Selenium Webdriver/Coypu) that get run by your Continuous Integration solution to make sure the system hangs together after each commit.
These aren’t hard and fast rules. There are other factors to take into consideration.
Is the team a a mixture of experienced and novice developers? Well, you can’t have one rule for one, and one for the another! Especially if everyone is going to work on all parts of the system.
Is the code going to be handed over to another team? Then you’d better do it TDD.
Perhaps these two scenarios mean you will always need to write tests for everything and my whole post is pointless!
Sorry, the comment form is closed at this time.