http://iit-iti.nrc-cnrc.gc.ca/publications/nrc-47445_e.html

The way most of these studies assess and measure “quality” is by having a large set of test vectors and corresponding expected (i.e. known good) results. This set is not known to the people doing the implementations. They may sometimes have a small subset as basic acceptance tests. With this kind of setup “quality” can be measured as the number of passing tests from the hidden set. This of course assumes that quality is correctness. Of course there may be other aspects to “quality”, that are not considered in this setup e.g. readability, flexibility, performance, modularity, etc. So as I said in this case “quality”=”correctness”.

A big problem with all of these studies is external validity (the authors are quite forward admitting that) so these results should be taken with healthy grain of salt – which is generally a good idea with these kinds of topics.

Test first forces you to think about a class/method/function/whatever from the point of view of clients of that code. ie. how is it going to be used rather than how I am going to implement it.

Also, if you find that the test requires too much setup, fixture code, etc then its telling you there is a problem with the class, there is too much coupling going on and there is almost always something missing. This also helps design.

My experience of teams that practice test later is usually a rapid degradation to functional test only and then test nothing, mainly because the coupling and code quality makes it harder and harder to test.

Test later also means missing things – how are you going to be sure that you’ve covered everything, I don’t mean in terms of code coverage but in terms of intent.

I am interested to know how the studies you mentioned measured quality, which is very difficult to do in a meaningful way.

It’s hard to prove this statistically, but it’s a good feeling that test-first leaves me with when I know the code works and is readable.