Application Testing

Question

Is the real benefit in TDD the actual testing of the application, or the benefits that writing a testable application brings to the table? I ask becuase I feel too often the converstation revolves so much around testing, and not the total benefits package.

Answer 1

Automated testing keeps humans from doing a machine's job.

Test-driven development maximizes the amount of automated testing.

Beyond a certain point, of course, a human is still required. You reach diminishing returns when you try to apply TDD beyond that point.

Answer 2

TDD helps you design your software. The tests becomes the design. By writing the test first you think about your code from a consumer perspective, making a more user friendly and more compact software design.

Also, by applying TDD you typically end up writing your code in a way where you can supply test mocks and stubs. This leads to less coupled software, making it easier to change and maintain over time.

So I guess allot of the talk around TDD is about testing, but by doing that other big benefits follow, such as quality (coverage), flexibility (decoupling), better design (think as the consumer of the API).

Answer 3

The real benefit of TDD is supposed to be that it allows you to modify/refactor/enhance your application without worrying about whether you've broken existing functionality. The fact that writing unit tests tends to result in loosely coupled code and better architecture isn't necessarily the point of TDD, but I think it's hard to have one without the other.

You can't really experience the benefit of TDD unless you have unit tests with good coverage. In order to do that, you're going to have to write testable code. That's why the two are often used in conjunction or in place of one another.

Answer 4

The real improvement is that it is a good way to force you to really think through the design and implementation. Then, once you've prepared the tests and written the code, solutions to unforeseen problems appear more easily.

Something that usually happens to me that is a good analogy: When I'm going to post a question to a forum or IRC channel, I like to have the problems well written and fully described, many times the process of preparing a well written and complete description of the problem magically makes the solution appear.

Answer 5

Automated testing is such a time saver and confidence booster when you are developing a product that you'll ship multiple versions of. With automated tests, you know that you haven't broken anything between versions. This especially helpful when your product is something that people can write add-ons for - you don't want to break their add-ons between versions.

With TDD, you get a good suite of tests as you develop. Without TDD writing those tests is much more difficult.

Answer 6

Michael Feathers has an insightful blog post about this titled The Flawed Theory Behind Unit Testing. Seriously, go read it. The punch line is

All of these techniques have been shown to increase quality. And, if we look closely we can see why: all of them force us to reflect on our code.

but you should read the full post for the context.