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.

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

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