The question what do I gain from doing TDD/BDD is asked quite often. I understand the reasons people ask for that. I have practised TDD since 2001. This post is an explanation of why I TDD/BDD and what I gain from it.
Why do I BDD?
BDD helps me with 3 aspects of software development: Design, Defense, Documentation.
- When I write the specifications(tests) first, I see that my design is simpler (as compared to write the code first) for given requirements, thus better.
- I know it's not very intuitive, you just have to try it.
- When you start with tests, your design is more testable.
- It makes debugging easier.
- TDD doesn't replace drawing diagrams.
- It's just an additional design technique.
- I still enjoy drawing UML-like diagrams!
- I feel much safer having my application covered with tests, .
- Thanks to that, I can do some refactoring when I feel it's needed, run the tests, and if it's 'green' I just check it in.
- Whenever some of my users find any bug, I prepare a test that covers it.
- Only then I fix the bug and release the change.
- There's nothing worse than having a bug that reappears again (after fixing it) in the application.
- I'm not a fan of big Word documents that describe all details of the requirements.
- It's just too difficult to synchronize this document with reality after every requirements change
- Changes are inevitable.
- There was one large project I was working on, where nobody from the team (including the project manager) knew what all the requirements were!
- Yes, it is pathological.
- I store all of the requirements as executable stories/tests.
- Before releasing any change I run all the stories.
- When there is a requirement change I just find the story responsible for that, change it appropriately and change the code.
- Changes are inevitable.
I know some very good developers that don't write any tests and are successful. There are other ways of ensuring good design or documentation. As for defense, you may have a very fast testing department that makes sure you didn't break anything. Or maybe you just prefer to manually go through your application. For me it's just too slow, I prefer an immediate response that is free of any human mistakes. Chances are, you are just so perfect that you don't introduce any breaking changes. Lucky you!
It's also possible that you separate the analysis, design and implementation phases so strongly, that there is no way of changing anything during the implementation phase. I'm not a big fan of this approach but I know that many people are successful with that. I believe that even in this case you can gain a lot from writing acceptance tests (executable stories). Writing unit tests for your classes is also a good thing. I'll try to cover the topic of testing on different levels (acceptance, units) in a separate post.
But it's difficult and expensive, isn't it?
First of all, it requires discipline. It takes some time to get used to write tests first.
Also, it takes some time to learn how to do correct TDD/BDD. The good news is that you can start introducing it gradually.
Another thing is that after creating a lot of tests for your applications the whole suite may take some time to run. It's a problem that is not easy to solve, but believe me you'd prefer this kind of problems than a 5-days debugging session.
Is it fun?
Yes, it's a lot of fun!
Again, you have to try it before you know, what I'm talking about. If you're still new to TDD, look around, maybe there is someone experienced nearby who can show you a quick demo.
Feel free to ask me questions about TDD or BDD. I have practised it with Java, C#, IronPython and Ruby. The technology doesn't matter too much in this case. You can use comments for that or simply email me at andrzejkrzywda at gmail.com.