TDD is a means to an end, not an end in itself. I think some TDDers lose sight of that fact.
The end is well-tested code. Developers often lack the discipline to write tests after writing what appears to be working code. The point of TDD is to force that discipline by making it part of the process of writing the code in the first place.
It's a good technique that many use to great effect, but it is just that, a technique, not a goal in itself.
What matters is that, when you're checking in new code and pushing it upstream, that code has tests along with it. Whether you wrote the tests right before the check-in, or as part of a TDD cycle, is immaterial to everyone else.
I would argue the "end" of TDD is working, well factored code. It's a technique for continually getting rapid feedback on every code change that you make, working in very small iterations.
The fact it results in a regression test suite is a happy side benefit (and actually, some of the tests generated are inevitably short lived).
There are other benefits of working in this style. e.g You should nearly always have code in a state that could be deployed to production; It gives a rhythm for pair programming; It encourages a certain coding style.
Comments
TDD is a means to an end, not an end in itself. I think some TDDers lose sight of that fact.
The end is well-tested code. Developers often lack the discipline to write tests after writing what appears to be working code. The point of TDD is to force that discipline by making it part of the process of writing the code in the first place.
It's a good technique that many use to great effect, but it is just that, a technique, not a goal in itself.
What matters is that, when you're checking in new code and pushing it upstream, that code has tests along with it. Whether you wrote the tests right before the check-in, or as part of a TDD cycle, is immaterial to everyone else.
I would argue the "end" of TDD is working, well factored code. It's a technique for continually getting rapid feedback on every code change that you make, working in very small iterations.
The fact it results in a regression test suite is a happy side benefit (and actually, some of the tests generated are inevitably short lived).
There are other benefits of working in this style. e.g You should nearly always have code in a state that could be deployed to production; It gives a rhythm for pair programming; It encourages a certain coding style.