Why should I use Test Driven Development? [duplicate]

Answer 1

Here are three reasons that TDD might help a developer/team:

• Better understanding of what you're going to write
• Enforces the policy of writing tests a little better
• Speeds up development

One reason to write the tests first is to have a better understanding of the actual code before you write it. To me, this is the main benefit of test driven development. When you write the test cases first, you think more critically about the corner cases. It's then easier to address them when you write the code and ensure that they're accurate.

Another reason is to actually enforce writing the tests. Often when people do unit-testing without the TDD, they have a testing framework set up, write some new code, and then quit. They think that the code already works just fine, so why write tests? It's simple enough that it won't break, right? But now you've lost the advantages of doing unit-tests in the first place (completely different discussion). Write them first, and they're already there.

Writing these tests first could mean that you don't need to launch the program in a debugging environment (slow — especially for larger projects) to test if a few small things work. Of course there's no excuse for not doing so before committing changes.

Convincing yourself or other people to write the tests first may be difficult. You may have better luck getting them to write both at the same time which may be just as beneficial.

Answer 2

Ideally:

You won't waste time writing features you don't need. You'll have a comprehensive unit test suite to serve as a safety net for refactoring. You'll have executable examples of how your code is intended to be used. Your development flow will be smoother and faster; you'll spend less time in the debugger.

But most of all, your design will be better. Your code will be better factored - loosely coupled, highly cohesive - and better formed - smaller, better-named methods & classes.

Answer 3

I personally do not use TDD, but one of the biggest pro's I can see with the methology is that customer satisfaction ensurance. Basically, the idea is that the steps of your development process are these:

1) Talk to customer about what the application is supposed to do, and how it is supposed to react to different situations.

2) Translate the outcome of 1) into Unit Tests, which each test one feature or scenario.

3) Write simple, "sloppy" code that (barely) passes the tests. When this is done, you have met your customer's expectations.

4) Refactor the code you wrote in 3) until you think you've done it in the most effective way possible.

When this is done you have hopefully produced high-quality code, that meets your customer's needs. If the customer now wants a new feature, you start the cycle over - discuss the feature, write a test that makes sure it works, write code that passes the test, refactor.

And as others have said, each time you run your tests you ensure that the old code still works, and that you can add new functionality without breaking old one.

Answer 4

TDD (Test Driven Development/ Design) provides the following advantages

• ensures you know the story card's acceptance criteria before you start
• ensures that you know when to stop coding (i.e., when the acceptance criteria has been meet thus prevents gold platting)

As a result you end up with code that is

1. testable
2. clean design
3. able to be refactored with confidence
4. the minimal code necessary to satisfy the story card
5. a living specification of how the code works
6. able to support a sustainable pace of new features

Answer 5

Presumably you test code that you've written before you commit it to a repository.

If that's not true you have other issues to deal with.

If it is true, you can look at writing tests using a framework as a way to automate those main routines or drivers that you currently write so you can run all of them automatically at the push of a button. You don't have to pore over output to decide if the test passed or failed; you embed the success or failure of the test in the code and get a thumbs up or down decision right away. Running all the tests at once reduces the chances of a "whack a mole" situation where you fix something in one class and break something else. All the tests have to pass.

Sounds good so far, yes?

The TDD folks just take it one step further by demanding that you write the test FIRST before you write the class. It fails, of course, because you haven't written the class. It's their way of guaranteeing that you write test classes.

If you're already using a test framework, getting good value out of the tests you write, and have meaningful code coverage up around 70%, then I think you're doing well. I'm not sure that TDD will give you much more value. It's up to you to decide whether or not you go that extra mile. Personally, I don't do it. I write tests after the class and refactor if I feel the need. Some people might find it helpful to write the test first knowing it'll fail, but I don't.