It's like unit testing. The idea of writing code to test your code was so blindingly obvious to me from the time I started programming that I was shocked that it took so long for other people to pick up on it, but the concept of "unit testing" started to gain some traction around the late 90's and I was relieved that somebody with some authority was advocating it.

But the reason I didn't just do it myself before Kent Beck published JUnit was because the code I worked on didn't lend itself well to being controlled by other code. Global variables everywhere, widely distributed state, dependence on external systems and specific file system layouts and general disregard for modularity made it impossible to run anything outside of the context it was designed in. All of this was "bad design", but it met deadlines, so everybody did it anyway. I was _hoping_ that if unit testing gained some traction, programmers would get away from monolithic design.

After 25 years of observing unit tests for getters and setters and then one big unit test that creates an in-memory database because every function in the app needs a live database just to run and then gets commented out because it fails, I've lost any faith that unit testing will ever be more than a meaningless checkmark that everybody fills out because it's a "best practice" but nobody actually stops to think why.

I've seen similar as well. Aggressive scrum has also made this much worse by laying all the incentives at "ship now and let the poor sap later who has to work this figure it out. I got my 'story points' and shipped so I won't be under the metrics microscope." Having a general requirement of "each code change should have tests in order to pass code review" can definitely help, but it doesn't incentivize good tests, and IMHO the only thing worse than no tests are bad tests.

I'd like to believe that "everybody" and "nobody" in your story aren't as black-and-white.

Many people see the value of unit testing. And see how TDD actually shapes your code to be testable and (accidentally, well, not really) therefore also cleaner and better organized.

I've always said, and will continue to do so: good, maintainable code, is accidentally also very well testable code. And vice-versa. And it's not a real accident, if you think about it.

But it only takes one person who either doesn't care or doesn't understand to make testability impossible for everybody else. And that person is usually management's favorite because he ships "on time, under budget".

I've ran from such places. Luckily for every such management, there are many more managements that understand the correlation between short term and long term gains.