A test is "an example of the rule in practice", but...

In Jason Gorman's post called Tests Are Instances Of Rules he says:

In test-driven development, we use tests as executable specifications of what is required of the software we create.

For this to work effectively, our tests have to convey the underlying intent. And this requires us to ponder the relationship between a test and a specification.

First of all, what is a specification? Well, in simple terms it's just a rule. A rule that the software must obey. For example, it might be a rule that says that we cannot transfer money from one bank account to the same bank account.

We can test this rule by trying to transfer money from Jill's current account with ID 12345678 to Jill's current account with the same ID.

That is not the rule. The rule applies to every account, not just Jill's. That we cannot transfer money from Jill's current account to the same account is an example of the rule in practice. In much the same that 12345678 is an example (or "instance") of a bank account.

I like the phrase he uses where he says that a test is "an example of the rule in practice"...

The way that Jason words it thereafter, however, is where his idea of TDD and mine diverges slightly.

Although I may have an idea of the rule in my mind before I've even written the first test, I'm treating that as merely an hypothesis. Indeed I may make my own predictions about the rule that may result... i.e. applying the Scientific Method (see my example of the scientific method applied to another aspect of testing). I then try to put the rule out of my mind so that I minimise how it might bias my choice of test... I want my tests to be (as Jason says) "examples of the rule in practice"... but I want to do that as much as possible as if I had no prior knowledge of the rule... I want the rule to be inductively inferred from the examples (or tests) rather than the tests to be inferred from the rule. This ensures that the implementation evolves in a valid direction - in the context of a unit test valid according to how I or other developers may use a class... or more often how that class' clients may use it.

There are some cases where the rule is what the rule is and it's ok to make that more explicit in the test... But when the test looks too close to the implementation then I ask: Am I merely codifying the rule in my test and 'paraphrasing' it in the implementation? Are my predictions about the rule biasing my tests?

So, in subtle contrast to the way Jason has described the relevance of rules to code and tests, I would say:

In TDD tests are examples of anticipated usage, from which we infer the rules. The rules should be clearly described in the implementation code... why that is the rule should be clearly described in the test code by how the examples are expressed