|
|
|
|
|
|
by rads
5224 days ago
|
|
|
It depends on the person. Does writing tests help you understand the problem, and if so, does that help you solve it faster? Only you can answer that. Here's a quote from Rich Hickey that really struck home with me: > I never spoke out 'against' TDD. What I have said is, life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I’m sure that’s not true for me—I’d rather spend that time thinking about my problem. I’m certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design. (http://www.codequarterly.com/2011/rich-hickey/) Another question to ask is does this help others understand the problem? You often don't write tests for yourself, but for other people, including the later you that has popped the problem off the mental stack long ago. Writing tests might lose you time right now, but the net gain of time saved by others may make up for it. Let me emphasize the word "may", because you might make the problem clearer by writing documentation in English rather than code. So the only conclusion is that it depends, it depends... |
|
|
The benefits of using tests as documentation come regardless of religious adherence to test-first, and in my opinion are often hindered by it. I agree that tests can make great documentation, as well as adding value for a number of other reasons (regression, etc).
I severely question the concept of writing them first in all (or even most) cases, though.