I think we're talking specifically test automation like unit tests, integration tests, and end to end tests. You can't write software without ever trying to run

I think we're talking specifically test automation like unit tests, integration tests, and end to end tests. You can't write software without ever trying to run it, which is functional testing. A solo developer e.g. has to be doing these sorts of "QA"/functional manual testing. Let's look at the source code for Doom: https://github.com/id-Software/DOOM https://github.com/id-Software/DOOM How many _test files do you see? Millions of people played Doom for endless hours and the quality beats a lot of modern software with tests. Again, tests certainly have their place in modern software development, but the kind of thinking that if you have tests that means your quality is good is wrong and actually leads to worse software quality. Tests are just a part of an overall approach to quality software. EDIT: Re hiring. I would be looking for people that understand the nuances and the why vs. people that approach things through a religious lens. I.e. they understand the tradeoffs. If you're writing tests then your tests are code. Should you write tests for your tests? If not why not? How do you know that your tests are correct? If your religion says 100% unit test coverage for all code then it's pretty clear this is a religious belief not subject to reason (because otherwise you'd be also asking for 100% coverage for your unit test code by other unit tests). There are situations where unit tests have a ton of leverage. There are situations where they have less. Testing happens in other disciplines, e.g. mechanical engineering, where certain things get tested (including with automation) and others do not. The decisions depend on the function of the component, the impact of failure, preexisting knowledge about the technologies, etc. software engineering can learn something from some of those other engineering disciplines...