[Morgawr]

I don't honestly understand what is the point of this. How does time spent writing something have to do with the quality of it?

Tests are supposed to be simple and straigthforward, I would hope to spend less than 5% of my time actually writing tests. If I spend more then it means that my tests are too complex to understand, read and write and that my whole architecture is hard to test.

Are we trying to evaluate quality of code (yes, tests are code too) by the amount of time spent writing it? Should we go back to assembly because it takes us longer to write it properly hence it's more correct?

I honestly don't understand the point, enlighten me, please.

[inventitech]

The first step is just to observe how much time is spent on testing. We have basically no clue about this. And our first study with students has also shown that they had no clue about it.

In a second step, we can think about which implication testing time might have on quality. As you said correctly, more time does not necessarily correlate with better quality or higher productiveness. Maybe there is a certain range of testing efforts that can be associated with good quality tests? E.g. if you spend less than x on testing, your tests are likely to be bad. If you spend more than y on testing, it might be worth investigating whether you have unusually high testing targets. Or your tests might be extremely hard to maintain.

I think the answer is Janus-faced and there is no single, simple answer (see also "Testivus on Test Coverage", http://www.artima.com/weblogs/viewpost.jsp?thread=204677).

[jmathai]

The longer I've written tests the truer this becomes. Nowadays it doesn't take me much time to write the tests. I'm not a TDD zealot but I often write tests in conjunction with a new feature. I've found that it makes the overall process faster, resulting code simpler and interface to the code more consistent.

A small investment of time writing tests before implementation yields the best overall results across the board.