A big issue with TDD is people don't know how to write tests. People tend to write covariant tests where if details of the implementation changes, then the tests fail, even if the code is working correctly. These tests are easy to write, but bring very little benefit. There's another kind of test that few people write that solves this problem: they're contravariant. The detail implementation can change and yet contravariant tests can test that the code is still working correctly. In other words, you can refactor code and still use your existing tests to ensure the refactor didn't break anything. You don't re-write your test.

Another benefit of contravariant tests? It's very difficult to create them if your architecture and design is poor. Contravariant tests lead to good architecture and design.

Bob Martin discussed these issues in his blog a few years back. https://blog.cleancoder.com/uncle-bob/2017/10/03/TestContrav...

Is there any prior art that defines covariant/contravariant tests in this way, or is Martin just borrowing language that sounds cool?

Bob Martin was the first to use the terms covariant/contravariant in the context of software development, as far as I'm aware. Using this precise language borrowed from mathematics at once clarifies both the problem and the solution that folks like Kent Beck and Dan North had been talking about for decades. Now we can discuss these issues with a whole lot less hand-waving.

>Test-Driven Development (TDD) doesn’t make sense to me, especially when requirements change frequently.

If requirements change SO fast that it's enough to render the tests that validate them completely obsolete then writing any kind of production code at all makes no sense.

Spikes, customer research, POCs, MVPs... these things all make sense but none of these are production code and hence none of them require TDD.

>Ultimately, while TDD might work in stable environments

i.e. production code. Not all of us write production code and thats fine.

> When I develop a feature, I usually follow these steps:

  1 Make it work: a mandatory, crappy implementation that gets the job done.
  2 Make it right: a nice-to-have step, improving code maintainability and reusability.
  3 Make it fast: by this point, I’m already moving on to the next class or method, driven by the need for speed.

What does #2 mean to you? Why not cut it out for speed?

A natural way to use an LLM for coding is to create tests and ask it to write code that passes those tests, so I disagree with the author.