While it can be a useful forcing function, I find it also just fits into a higher velocity workflow in general, one I would describe like so:

1. Make PRs small, but not as small as you can possibly make them.

2. Intend to write at least one nice-ish test suite that tests like 50-80% of the LOC in the PR. Don't try to unit test the entire thing, that's not a unit test. And if something is intrinsically hard to test - requires extensive mocking etc - let it go instead of writing a really brittle test.

3. Tests only do two things: help you make the code correct right now, or help the company keep the code right long term. If your test doesn't do either, don't write it.

4. Ok - now code. And just keep in mind you're the poor sod who's gonna have to test it, so try to factor most of the interesting stuff to not require extensive mocking or shit tons of state.

I've found this workflow works almost anywhere and on almost any project or code. It doesn't require any dogmatic beliefs in PR sizes or test coverages. And it helps prevent the evils that dogmatic beliefs often lead you into. It just asks you to keep your eyes open and don't paint yourself into a corner, short term or long term.

One more piece - if the test would be hard to write, use that to drive you to clean up the architecture of that piece of code.

I call this "outside-in programming". The synthesis of TDD and API design.

And only write tests against the API you are responsible for.

Never let tests depend on implementation details.

I'm not disagreeing with you but there's a large number of programmers who viscerally disagree with "test first".

https://www.youtube.com/watch?v=NyiMOmCqu00

Casey is a game programmer.

In tests in a web application/api, your tests can actually be real use cases quite easily and design your api around real use cases.

How would you do that in a game? Check a frame looks a certain way?

I have done proper testing a puzzle game where the game can be represented by abstract state. But modern 3d rending is hard to test well.

I think it's easy enough to design code that is easy to test - simple single-purpose functions/methods that are self-contained and don't change any global state, etc, and obviously you need to document what the input/output guarantees are, and I would normally add assertions at time of coding to enforce those.

Where you are going to run into difficulty in testing is if your APIs are so complex that it's all but impossible to exercise all code paths by testing with different parameters, or if functions have global side effects (bad practice).

I'll add that retrofitting good tests is almost impossible. Too many people write tests against working code that just tests what they know the code already does. At best these are regression tests. If you write tests first you are forced to think about what you want the behaviour of the software to be before you've gone deep into a solution and forgotten about the original problem.

Even if you aren't going to do the complete test code just writing down the expected checks for each test makes things so much easier