I think others have made the point well: tests give you the confidence to refactor and change and know if you broke something a customer expects to work. One ca

I think others have made the point well: tests give you the confidence to refactor and change and know if you broke something a customer expects to work. One caveat is that they should be good tests and not overly coupled. Don't mock as those are brittle. How so? Usually mocks assert more than contracted behavior. If you have a method under test, it doesn't matter what its guts are doing. You shouldn't assert its state. What matters is that its observable actions and errors behave as expected. You don't assert that internal functions of that method are called so many times in such and such order with the right arguments. Just test at the exposed edges. You will want unit tests this way and to verify error handling and logic flow. You will want integration tests or acceptance tests to verify things work together and can perform the actions your users will take. These pay dividends and prevent the manual need to verify you did not break anything on a given change. You also don't need to exhaustedly test everything. Start with critical parts. And, like others said, add to your test suite any bugs to prevent regressions. A paying customer who reports a bug, sees it fixed, and sees it come back is not a happy camper.