Originally written in French. Translated by AI — the meaning has been preserved, not the prose.
Main idea
An assistant asked for tests once the feature is written produces tests that pass. That is to be expected: it derives them from what it has just written. They check that the function called with such an argument returns what it already returns, that the component displays what it already displays. If the implementation misunderstood the need, the tests ratify that misunderstanding and protect it against any future correction.
The visible effect is the opposite of the real one. The repository shows hundreds of green tests, the suite runs on every change, and the product looks safe — while nothing in that setup has ever confronted the code with the behavior the business expects.
That is what separates coverage from a test strategy: the first measures how much code is traversed, the second decides which behaviors must stay true, at what level to check them, and which risks must be covered.
Why it matters
It prevents the presence of tests from being read as proof. On generated code, the number of tests is the easiest figure to obtain and the least informative: you have to know where they came from — from an intent stated beforehand, or from an implementation reviewed afterwards.
It also explains why the subject is hard for a product profile. They may have no practice of test-driven development, may not always tell a unit test from an integration test or an end-to-end test, and have never had to express a business rule as a check — so they have no way of spotting that what is handed back to them is a mirror.
Nuances and limits
A test written after the code is not worthless: it guards against regressions, and that is already a lot on code nobody rereads. What it does not do is establish that the behavior was the right one.
And reversing the order is not enough either: a test written beforehand, but by someone who misunderstood the need, fails in exactly the same way.
Open questions
- How can someone who has never practised testing express a business intent in a verifiable form, without first relearning the vocabulary of testing?