I was explicitly told not to write unit tests because they took too much time, which required me to spend entire days retesting almost 100 scenarios when the business logic changed.
Of course the business didn't know all the scenarios at the beginning of the feature development and didn't care because: iterative development means we'll figure it out later.
A lot of devs trap themselves by insisting they can write the tests after. Once managers know the code exists they want to use it, or move on to the next thing people are breathing down their necks for. And code written without tests is difficult to test so becomes a self fulfilling prophecy.
In fact it’s such a reliable mechanism for self sabotage that I look at carefully at people who bring this on themselves and try to figure out if it’s naïveté, learned helplessness, or malice.
As you've discovered, good automated testing is mandatory for iterative development. If execs tell you to do something unprofessional, it's ok to say no. Indeed, if we're going to think of ourselves as professionals, I think it's mandatory.
But one developer quitting rather than do bad work does change something. At the very least, it means that the developer can find another, better job. But it's also an opportunity for companies to learn. And for those who don't, good people refusing to prop up bad companies is a step forward.
I'd also add there's a a lot that can happen between refusing to do bad work and quitting/getting fired. Saying no is the beginning of a negotiation. A negotiation that won't happen if we just say yes all the time.
Of course the business didn't know all the scenarios at the beginning of the feature development and didn't care because: iterative development means we'll figure it out later.