> It sounds to me like you're arguing from a position where tests are expensive and time consuming to write.
Of course they are. Tests are code. As a rule of thumb, sufficient coverage requires writing three times as many lines of code for the test suites than for the code it's testing. You need "sufficient coverage" to get the benefits of "I completely forgot these parts of the codebase, but I can make changes without fear of breaking something, because wherever I would need to make changes, there are tests covering it". 3:1 test to application ratio means that it's roughly four times as expensive compared to a completely untested codebase; compensating for the cost of manual testing, so perhaps three times as expensive.
If you're only writing tests for a small portion of the codebase - a complicated section of the business logic, say - see (a) in the original comment, where I do see value in writing tests up front. But that doesn't provide full coverage.
I gave a talk at DjangoCon today about how I maintain 185 projects as a solo developer... thanks to a habit of comprehensive tests and documentation for every one of them. Video online soon, slides and notes are here: https://github.com/simonw/djangocon-2022-productivity
I am confident I would not be able to productively maintain anything near this much software without those tests!
Of course they are. Tests are code. As a rule of thumb, sufficient coverage requires writing three times as many lines of code for the test suites than for the code it's testing. You need "sufficient coverage" to get the benefits of "I completely forgot these parts of the codebase, but I can make changes without fear of breaking something, because wherever I would need to make changes, there are tests covering it". 3:1 test to application ratio means that it's roughly four times as expensive compared to a completely untested codebase; compensating for the cost of manual testing, so perhaps three times as expensive.
If you're only writing tests for a small portion of the codebase - a complicated section of the business logic, say - see (a) in the original comment, where I do see value in writing tests up front. But that doesn't provide full coverage.