quarantine 'em

We tried adversarial TDD at work once, as an exercise. One person writes one test, the other writes the minimum of code to make it pass

We discovered that if e.g. the first test case expects a method to return 1, the first implementation of the method will return 1 every time

If the second test case expects 2, the implementation will simply be revised to return 1 and 2 alternately.

The tester had to write a *lot* of tests before the developer gave up and implemented the implementation that was really being tested for

And in principle, there is *no* point at which the developer genuinely has to give up. They can fake a working implementation forever.

If the tester and the developer are not on the same side, it is VERY difficult for the tester to force out the implementation they want

This is at the unit test case level. At higher levels, fakery becomes harder, but is still possible if the developer is motivated

The crucial point is this: it needs to be impossible to computationally distinguish an emissions test from regular driving