That actually wasn't why I didn't write tests a lot of the time.

What stopped me was that after a year of writing tests, I was moved to a higher priority project, and the person who followed me didn't write tests.

So when I came back, many of the tests were broken. I had to fix all those in order to get new ones to not be a bother.

Repeat again, but this time I came back and the unit testing suite had fundamentally altered its nature. None of the tests worked and they all needed to be rewritten for a new paradigm.

I gave up on tests for that system at that point. It simply wasn't worthwhile. Management didn't care at all, despite how many times I told them how much more reliable it made that system, and it was the only system that survived the first giant penetration test with no problems.

That doesn't mean I quite testing. I still wrote tests whenever I thought it would help me with what I was currently working on. And that was quite often. But I absolutely didn't worry about old tests, and I didn't worry about making sure others could use my tests. They were never going to try.

The final straw, less than a year before I was laid off, was when they decided my "storybook" tests weren't worth keeping in the repo and deleted them. That made me realized exactly how much they valued unit tests.

That isn't to say they had no tests. There was a suite of tests written by the boss that we were required to run. They were all run against live or dev servers with a browser-control framework, and they were shaky for years. But they were required, so they were actually kept working. Nobody wrote new tests for it until something failed and caused a problem, though.

tl;dr - There are a lot of reasons that people choose not to write tests, and not just for job security.

Well this wasn’t really aimed at individual devs, but the team/company standards.

I’ve worked at several teams and it was always the norm that all PRs come with tests. There was never a dedicated QA person (sometimes there would be an eng responsible for the test infra, but you would write your own tests).

I would never accept a PR without tests unless it was totally trivial (e.g. someone mentioned fixing a typo).

A broken environment engenders broken behavior and this explains is why it is bizarre, not that it isn't bizarre.

Breaking prod repeatedly probably impacts your stack ranking too.

Once, for a very very critical part of our product, apart from the usual tests, I ended up writing another implementation of the thing, completely separately from the original dev, before looking at his code. We then ran them side by side and ensured that all of their outputs matched perfectly.

The "test implementation" ended up being more performant, and eventually the two implementations switched roles.