By far the best codebase I ever worked with had zero test cases, was nearly 30 years olds, been worked on by not just several teams but several companies, had basically zero documentation, and was still easy to read and understand.
Unit tests only really catch a tiny fraction of bugs relating to defective code, not poor design, poor market fit, poor understanding of requirements, or any of the other bugs that most often make it into production. They can be a huge benefit to many possibly most projects, but there are no silver bullets, good quality needs competent people given sufficient time and resources and nothing really changes that equation.
> not poor design, poor market fit, poor understanding of requirements, or any of the other bugs that most often make it into production.
That's because unit tests aren't supposed to be a magical silver bullet that automatically fixes everything. Unit tests are like an exercise regimen. Just because you work your ass off in the gym doesn't mean that you'll get the result you want. If you're still eating a massive amount of calories, have inconsistent workout patterns, or do exercises incorrectly, you will only see minimal gains. Likewise, if your unit tests are not testing the correct logic, it's just an exercise in futility.
People make jokes about the infamous null test:
Person p = new Person();
p.setName("a");
p.setAge(0);
assertNotNull(p);
assertNotNull(p.getName());
assertNotNull(p.getAge());
Yet there are a non-zero number of production code bases with those kinds of tests attached to them. And I firmly believe that this is one of the drivers of hatred towards unit tests: people see poor unit tests like the above, so they instinctively write off unit tests as a waste of time.
Just because someone uses a tool incorrectly doesn't mean that the tool does not have value. A spudger isn't going to drive a nail into the wall, but that's not what a spudger was designed for.
I worked on one such system (written in Ada, of all things) back when I was a fairly junior developer. I was hired to work on a major effort to port the system from SPARC/Solaris to RHEL/x86 and add some new features. It was designed by a crusty (and eccentric) old architect (who was still around to manage this major refresh project) who ruled with an iron fist, and the project was managed in classic waterfall fashion.
He was not afraid to look you in the eye and say: "Your crappy code is not going into my codebase until you fix X, Y, Z, and change your indents to match the style guide." There were no "unit tests", per se, only a test driver program that he had written himself.
He was a hard guy to like, but I had to admit, that system had a clean, coherent, and modular design the likes of which I haven't seen since.
That would be an ... interesting work environment. Probably the dev version of benevolent dictator, works great until the leader leaves, and the team is left with weaker control structures.
Not sure where you are going with this story. Do you mean that tests are useless, because you once worked in a company that thought that a large, test-less codebase was a good idea?
No, because I have worked with several dozen code bases, hundreds if not thousands of bugs, and Unit Tests are if anything a bad sign associated with code in desperate need of refactoring. They are the uncanny valley of quality.
Ed: Unit Tests become more valuable as code quality decreases.
Hmm... You're capitalizing "Unit Tests" like there's a need to distinguish the difference between those and what I infer is "code that was not Unit Tests that we ran to verify correctness". Am I correct? Are you drawing a distinction? Or did you truly have no code used to verify correctness? Or no automated way to test?
There are many types of tests, Integration tests are different than Unit Tests. Having a script click on UI elements is fundamentally different from isolating a function to verify it does what it should.
What about all the shitty 30 year code bases with no tests and no documentation that got dropped because they were garbage.
It's not impossible to write good code without tests, it is just more likely that code with tests and docs will be good enough to survive 30 years. Your project with no tests or docs and was good might be 1 in a million, while software that is good with tests and docs might be 1 in 100.
The test that are written today will not cover future cases 30 years down the road. Code bases 30 years ago are not the same shitty code bases you see today. Programming was more difficult and required better programmers who wrote better code on average. TDD is needed today because the bar has been lowered and it acts as a safety net.
Unit tests only really catch a tiny fraction of bugs relating to defective code, not poor design, poor market fit, poor understanding of requirements, or any of the other bugs that most often make it into production. They can be a huge benefit to many possibly most projects, but there are no silver bullets, good quality needs competent people given sufficient time and resources and nothing really changes that equation.