From Reddit.com:
Meta-analysis of over thirty studies found no consistent effect from TDD. One clear finding was that the better the study, the weaker the signal.
Greg Wilson's lecture: http://vimeo.com/9270320
and book http://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321
Wilson's post about the subject: http://www.neverworkintheory.org/?p=139
Meta-analysis of over thirty studies found no consistent effect from TDD. One clear finding was that the better the study, the weaker the signal.
Greg Wilson's lecture: http://vimeo.com/9270320
and book http://www.amazon.com/Making-Software-Really-Works-Believe/dp/0596808321
Wilson's post about the subject: http://www.neverworkintheory.org/?p=139
I’m still not sure what to think about test-driven development. On the one hand, I feel that it helps me program better—and feel that strongly enough that I teach TDD in courses. On the other hand, studies like this one, and the other summarized in Erdogmus et al’s chapter in Making Software, seem to show that the benefits are illusory. That might mean that we’re measuring the wrong thing, but I’m still waiting for one of TDD’s advocates to say how we’d measure the right thing.
The benefits from TDD come in a few different forms:
1) Change. As designs change and evolve, test harnesses reflect the original design and should provide a consistent framework for validation. They may need to be adapted to major design changes.
2) Simple validation. Verifying that you code works... both in the test harness and the production code written.
3) Understanding. If you can create a strong test harness, you'll have a much better idea of what the flow of data is and how it will be consumed. Without this, you are only guessing.
4) Workflow. For mid-level and junior programmers, this provides a consistent workflow and helps build good habits for testing production code.
5) Speedier production. Often, you do not have access to the consumer of your interfaces. This allows you to work in a vacuum and people can refer to you harness when trying to understand how to use your code.
6) Automated test. Your harness can be part of you build and guarantee the status of many parts of your build without running your code.
For all of these reasons and more, TDD just works. I have worked on many failed teams that do not use TDD. I have worked on three teams who used TDD and all three shipped on time and under budget. I have never worked on a team that uses TDD that has failed.
2 comments:
What does TDD mean? meet and greet Heathrow
Informative post. cheap luton airport parking
Post a Comment