Agreed, people tend to over complicate and make testing religious. In reality, testing is nothing more than a means to an end. Ask yourself these questions for

Agreed, people tend to over complicate and make testing religious. In reality, testing is nothing more than a means to an end. Ask yourself these questions for your project: 1. Are there pieces that can be tested independently where verification is valuable? 2. What is the impact of a bug or regression? 3. What type of testing is most likely to uncover issues in my product given its architecture and domain? 4. Am I confident to refactor the code base without creating new bugs? etc. etc. Iow, testing isn't magic, it should be driven by business goals. For example, I use Rust which due its great type system makes some types of code "just work", however, Rust cannot prevent logic errors. This means when I'm writing 'algorithmic code' I tend to write heavy unit tests. When I write API driven code, I tend to use more integration/end-to-end style testing. Do what makes sense for your code and goals. Tests take time and need to be refactored, so they aren't free, but can be valuable.