[paedubucher]

This (my) little rant is of course hyperbolic, but I tried to make two points:

1. The actual specification is sometimes better reflected by the implementation than by some test cases. 2. Some test cases don't help you understanding what's supposed to be computed.

Of course, counterexamples could be made. Imagine a board game with a test function testing specific moves. Those test cases will help you understand the implementation a lot.

[dschuessler]

I agree with both of your statements. They are definitely important points to make about your observation. But your post seems to argue against Martin's standpoint and for the assertion that „Tests are not specifications.“

From the fact that there are some tests out there that are barely specifying anything, it does neither follow that tests are not supposed to be specifications nor that tests are not specifications in general.

I think these are important distinctions to make.

[paedubucher]

When you read the entire section of the book, Martin claims that those tests main purpose is to serve as a normative documentation. The developer can read the test case and then figure out what was meant to be programmed.

While it might be illuminating in some cases, it might be not helpful or either misleading in other cases.

It's like arguing that the main purpose of magazines is to lit a fire with them, because some of them are very flammable.

Tests are good to ensure that some property of the system that held true before still holds true after some modifications to the system has been made.