Test Driven Development, or TDD, seems to be very popular among some software developers, but most of us are still skeptical and not using it.
Those who use it say that TDD helps them to write better code faster. Those who do not use it often say they have tried it and it does not work.
How can some technique be very helpful to some people and not work at all for others? I think a part of the reason is what I used to call the “mock objects trap”, but now call the “TDD trap”…
Intro (TL;DR)
My name is David and I am coaching and teaching software development teams as a freelancer. In this video series, I want to show you things you can try to become better at developing software - alone and as a team.
You can view the videos on your own. Or you could do so together with others, maybe as an introduction to a learning lunch at your company or to a meetup.
Today I want to talk about test driven development. But I do not want to talk about how exactly it works or how to get started yet - I want to leave that for a future video.
Today I want to talk about how some people love it and some do not even want to try it again.
Those who love it say that it helps them write better code and that they are faster when doing TDD. And because they are faster, they also develop their software cheaper.
Those who do not like it say that they have tried it and it clearly does not work. Writing the tests beforehand slows them down. The existing tests prevent them from making changes. Keeping the tests green over time is a major effort for them.
And I think that, at least some of those people, have fallen into the TDD trap.
Question / Problem
I have seen the end result of this trap happen at different clients, and from the stories I hear, it usually starts somewhat similar to this:
Somebody decides that the team needs more tests. Maybe it’s a manager who sets a KPI or some team member who keeps insisting that some of the bugs would not happen if they had more regression tests.
Most probably, not everyone on the team fully buys into that idea. Everyone starts to write tests, but at least some of the team members only do so because they have to.
So, the team starts writing tests, but they never have a formal or informal training - neither internal nor external - because writing tests seems easy. One can learn JUnit in a few hours.
Some people try TDD. But they also do without formal or informal training, because TDD seems easy. Red, Green, Refactor.
But people do not take extra care to write good tests. They do not put effort into designing their tests;
A) because they have never learned how good tests look like and
B) because testing is still an after-thought for most.
They try TDD, but it does not really work. People have a feeling that it slows them down; writing the tests before the production code is super-hard and refactor? They don’t see anything to refactor after most “Green” steps, so they stop thinking about it at all.
But they produce a lot of tests. A lot of bad tests.
And then, after some months, they want to change something. But the tests get in their way. After every small change, dozens of tests are red. Even after valid changes.
They conclude that “TDD does not work here”. This team has fallen into the TDD trap.
Solution
The underlying cause of the problem here is that neither writing unit tests nor TDD are easy. Those are, like the game “Othello”, “a minute to learn, a life-time to master” - kind of activities.
And, to be honest, there’s a second underlying problem here. But that one would be totally off-topic for this video. Maybe for a later one ;)
Back to the first cause: TDD is rather easy to “learn”. I can explain the basic rules to you in 10 minutes, and then you can start to test-drive some code.
And this is exactly what I do at the beginning of the first day when I teach TDD trainings. So, what do I do with my training attendees for the rest of the two days?
After the ten minutes explanation, people are able to do the red-green-refactor circle.
But it feels unnatural for them. They get stuck a lot. They take steps that are too big and then have problems writing the next test. They write themselves into a corner, but they do not want to delete code or tests, so they do not know how to get out again. They write “bad” tests that make their lives harder down the road. And they forget the “refactor” step, so it’s actually red-green-red-green-… for them.
To practice TDD successfully, you need to know more than the basic rules.
You must learn to take really small steps, and to not write more code than what is absolutely necessary. Because whenever you write more code than necessary - even only a little more - the next step gets harder.
You must learn about triangulation and about which next test - out of the list of all possible tests - to write.
You must learn how to use the “specific / generic cycle” to drive your code an design.
You will rely on your individual judgement a lot, so you have to develop a “gut feeling” for good tests and good code.
And there is a lot more to learn.
Learning all these things takes time and a lot of practice. But with a little bit of guidance from someone who has done it before, you can learn some of them a little bit faster. And you can hopefully avoid some common pitfalls.
Conclusion
And the TDD trap is about those pitfalls.
It happens when people think that TDD is easy. They read about it and think that they can do it too.
They try it and it does not work for them. So, they conclude TDD does not work at all.
And it can be worse. Sometimes they create a mess while using TDD. They write bad tests and they keep all of them. And months later, when they want to refactor something or write a new feature, the bad tests get in their way.
Some of those people start to hate TDD. They write angry blog posts. Others just dismiss it, never use it again and joke about the people who are still using such an “obviously flawed” method.
But it does not have to be like that.
If you have had problems with TDD, or if you are just starting out, try to find people who are using it successfully. Go to user-groups or meetups. Go to conferences. Ask around. Ask on Twitter.
Try to find someone who has “been there” and tell them your story. Ask questions.
This can make learning TDD a much more “painless” experience for you.
CTA
Did you already have a bad experience with TDD? Do you think someone you know fell into the TDD trap? Please tell me in the comments!
Or, if you want a longer discussion, tell me on Twitter: I am @dtanzer there.
And do not forget to subscribe to this channel or follow me on Twitter, so you do not miss any updates.
