Monday, January 21, 2008

What do I gain from TDD or BDD?

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.
  • Design
    • 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!
  • Defense
    • 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.
  • Documentation
    • 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.
Do I have to TDD/BDD in order to be successful?

Well... No.

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?

Yes, it is. All I gain doesn't come for free.

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.

What next?

Find some TDD tools for your technology. I believe they exist for every programming language. Find a place in your application where you'd like to start testing. Start with something simple. Maybe assuring that a request to a given page is successful? Or maybe asserting that all the values in the Order class are calculated correctly? Make sure you run those tests after every change of your application.

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.

8 comments:

jdm said...

"The good news is that you can start introducing it gradually."

This is the one thing nobody ever told me. The TDD/BDD mantra is 'test everything,' which is paralyzing when you sit down to start a new project. By getting at a small piece of it, it's easier to see how things should work, and then you can apply it to other areas.

bewhite said...

I'm using TDD in the Rails project now but I would like to know more about BDD.

Can you compare these technics? When we should and when we shouldn't use each of them?

I understand that it is quite common question so maybe you can write another one post about it?

Andrzej Krzywda said...

jdm:

One test is better than no tests.
As you say, it gives you better feeling how it works.

bewhite:

Comparing BDD to TDD? Yeah, it might be a good post for the future. Thanks for the hint!

ooblogger said...

Just seen your blog (link from DZone), nice work!
Pozdrowka z Catford!

tomfmason said...

I would have to disagree with you in that BDD is difficult or expensive. There is a bit of a learning curve but after that it should be easy. The extra expense only comes in when working with inexperienced developers or using something like pair programming.

I write most of my specs for a user story before I write any actual spec code. This gives the team a chance to review it and make any adjustments. Applying the specs into spec code is basically a copy and paste operation after that.

Andrzej Krzywda said...

tomfmason:

Thanks for your comment.

Well, it takes some time to learn, and is not really that intuitive when you start doing TDD or BDD. This is why I meant expensive or difficult.

Actually, I think that BDD might be easier than TDD, it's usually better organized.

As for pair programming, I find it a good way of teaching people doing BDD. You have more time to explain the philosophy behind it. Also you can show many details, and the "flow" of being driven.

What framework are you using for specs? RSpec?

tomfmason said...

@andrzej

I am using rspec mostly. I have also worked with phpspec and pyspec as well. However, I find that rspec's syntax is the easiest to work with.

When I first started the hardest part was understanding the general concept behind BDD. I was thrown into a large project with no BDD or Agile/Xp development experience.

It took me a few days and a lot of googling to understand the basic concept. The good news is that rspec's syntax is really easy to work with. Intermediate or higher level rails developers shouldn't have a problem once they get the concept behind BDD.

Andrzej Krzywda said...

@tomfmason,

Thanks for your response.

I'm interested in your experience with PySpec. One of the projects I'm working on is Python-based. Is it stable enough to start using it?

Did you start with BDD without actually knowing TDD?

RSpec's is easy, indeed.