I like a lot the reassurance that an extensive test suite gives me. In my main project, we have more than 3000 unit tests and about 400 E2E. I never worry about doing refactoring, library updates, weird coupling between code - if all automated tests passes, it's very improbably that anything is seriously broken.
Definitively you have a compound effect here - the longer your project lives, the longer you are getting benefits out of investment into writing tests. In my project, I wrote some E2E 6 years ago, and since then run them in the order of few tousands times.
Besides, writing or not writing tests is a decision on the project or team level. It would be frustraing and not productive to be the only developer caring about tests. In the oposit case, changes without tests simply wouldn't be aproved.
Recovering interrupter with occasional relapses, lover of spreadsheets, blogger, programmer, adept debugger, conjurer of analogies, and probably other things.
I like the language of "improbable that anything is seriously broken." It highlights the fact that our tests are useful in providing some degree of comfort but also that we shouldn't solely rely on them and assume they catch everything.
Automated tests are a long running conversation we have with our system, and as both change, drift inevitably occurs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I like a lot the reassurance that an extensive test suite gives me. In my main project, we have more than 3000 unit tests and about 400 E2E. I never worry about doing refactoring, library updates, weird coupling between code - if all automated tests passes, it's very improbably that anything is seriously broken.
Definitively you have a compound effect here - the longer your project lives, the longer you are getting benefits out of investment into writing tests. In my project, I wrote some E2E 6 years ago, and since then run them in the order of few tousands times.
Besides, writing or not writing tests is a decision on the project or team level. It would be frustraing and not productive to be the only developer caring about tests. In the oposit case, changes without tests simply wouldn't be aproved.
I like the language of "improbable that anything is seriously broken." It highlights the fact that our tests are useful in providing some degree of comfort but also that we shouldn't solely rely on them and assume they catch everything.
Automated tests are a long running conversation we have with our system, and as both change, drift inevitably occurs.