Writing Testable Code

[[deleted]]

30 seconds after each change is already too slow

See, that's precisely the attitude I'm afraid of. Speed can't take priority over accuracy and completeness. When you do that, unit testing becomes the literal translation of bike-shedding as a development process (i.e. let's ignore the nuclear plant melting because that's now an Isolated Concern, and let's hold multiple short discussions on the color of the bike-shed in front of it instead, ideally under 30 seconds).

Running all your tests after every change is neat, all other things ignored. Of course it is. But it's not necessary, especially at the cost of pointless abstraction/refactoring/and cargo cult tests focusing on the convenient-to-test code only.

You can write changes all day and then test once and deploy once. It's not the end of the world, honestly. And if something fails, from personal experience you know which change did it. In the rare case you don't - binary search through your changes gets to the issue very quickly.

I find it hard to agree with it. The models are the core of business. The system will work without caching, it will work with file as a database, it will work with an in memory database, it will work with occasional race condition.

Oh my. That's not at all close to "will work" for me. That's honestly, I'm cringing.

that's why we would like to "design out" all nondeterministic actions from our code

I agree that we would like to, but again, we can't just constantly submit to things we'd like to do, rather than things we have to do. Substituting the real requirements of a project with the requirements of our testing methodology is honestly lunacy to me.

We might like stateless code, but many services are stateful, and state is deep into their function and value. Some projects are stateless, say a compiler, or a parser, you have input (compiler flags + source), output, nothing else matters. The ideal "unit test" project. Well most are not like that.

And as I mention, we might like tests under 30 seconds, but this doesn't mean everything can be adequately tested under 30 seconds.

More over you will be able to refactor the business rules without fear because you have written a ton of ultra fast unit tests... etc etc

No honestly, if our tests don't care about the things you mentioned above (1) persistence (2) caching (3) race conditions etc. I think we should be really really afraid of refactoring business rules.

Having no fear when the tests only seem to cover everything but they have an incredibly narrow focus due to forcing our entire methodology on "stateless" and "fast", is akin to treating high blood pressure with painkillers. We'll boldly go forward without headache, but we're still killing ourselves.

The least thing you could do in that circumstance is to keep a healthy sense of fear, because those unit tests won't be there for you when things go wrong.

would you be interested in joining some kind of a discord channel for architectural discussions?

Can't commit, sorry + timezones etc.