Score it before you read it

The volume of code a working engineer reads has gone up by an order of magnitude, and the volume they write has gone down. Reviewing is now the primary skill, and almost nobody has practised it deliberately.

Reviewing a *test suite* is harder than reviewing the code it covers, because a suite has no obvious failure. Code that is wrong eventually does something wrong. A suite that is wrong just sits there being green.

So the exercise is this: you are handed a suite somebody else wrote for a module. Before you run anything, you commit to a number — how much of this module's behaviour do you think this suite actually pins down? Then you run the board.