Do people actually send PRs with no tests? That is so bizarre to me
Developers may understand that "XYZ is better", but if management provides enough incentives for "not XYZ", they're going to get "not XYZ".
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.
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).
Rarely
Do people send PRs with just enough mostly useless tests, just to tick the DoD boxes.
All the time.
A concrete example would be adding say saml+scim to a product; you can add a library and do a happy path test and call it a day. Maybe add a test against a captive idp in a container.
But testing all the supported flows against each supported vendor becomes a major project in and of itself if you want to do it properly. The number of possible edge cases is extreme and automating deployment, updates and configuration of the peer products under test is a huge drag, especially if they are hostile to automation.
The "test implementation" ended up being more performant, and eventually the two implementations switched roles.
To put things in context, it both depends on organization standards, and what the change actually is.
Where I work, there are areas that, if you change, you must update the tests. There are also development helper scripts and internal web sites where "it compiles" is good enough.
Likewise, I've done quite a bit of style cleanup PRs where the existing tests are appropriate.