Testing can be pretty contentious until you live through a few weeks or months of bad deployments and delays. As an application matures and complexity increases

Testing can be pretty contentious until you live through a few weeks or months of bad deployments and delays. As an application matures and complexity increases, you'll need to ensure that a benign change in one component doesn't cause something else to fail. The only way to do this is introducing testing to the ci/build process and letting the developer know what needs to be fixed before their work can be integrated. Younger me hated tests. More experienced me sees tests as a necessary part of building high-quality software. Younger me didn't like tests because: * Writing the test can be more difficult and time consuming than writing the feature you are testing. * Tests redefine what "done" means for a new feature by adding "tests pass". That means it will take more time and attention to detail to finish. * Finally, tests introduce a new constraint: you have to take tests into account when you change code and that slows down development, too. All of the above said, there's definitely a sliding scale of too little/too much when it comes to tests that ranges on complexity and the developers working on the software.