> Are you going to actually get things done faster or better? Seems unlikely, especially in a world where requirements shift every five minutes and are ill-defi

> Are you going to actually get things done faster or better? Seems unlikely, especially in a world where requirements shift every five minutes and are ill-defined in the first place. What is the value of tests? If requirements are going to shift every five minutes then sure, tests hold you back. Tests in an inherited codebase defined how the system needed to work, not how the system will adapt to changing requirements. Often, particularly for small-enough and simple-enough systems, a human eye is much more flexible than any tests you could write in code. But the fact of the matter is that the utter majority of software that runs in production (note that qualifier - excluding code that never makes it into production for a variety of reasons), stays in production. It's a corporate cash cow of one kind or another. Software in production needs to be maintained. Software vulnerabilities are reported, old versions hit end-of-life. Java 4 -> Java 5 -> Java 6 -> Java 8 -> Java 11 -> on and on and on. So the business case is very simple. You're forced to make changes and you want to make sure those changes don't kill your cash cow. Tests check your application at run-time. Types check your application at compile-time. As a result they can provide both more dependable and quicker guarantees than waiting for a run-time test suite to finish running. If you don't understand the value of tests, you haven't worked on a large enough, mature enough system, where the original engineers have all long left the company.