Once you understand good design and the benefits, you don't go back.
One of our projects at work has nearly 800 tests in it (across 5 test projects). The point isn't that we have 100% test coverage (because I doubt we do). The point is that we know how a method behaves when sent empty and null values, and also for nearly every edge case in addition to the happy path.
Most of these are 800 tests are logical unit tests. Some are system integration tests (parts of the system working with each other). And few are integration tests (tests that touch resources external to the code such as a database).
We also have an end-to-end project that has a number of black box tests in it that is not included in this number.
Oh, and the project in question is under 2,000 (LOC) lines of code.
This is by far the best designed and adaptable code that I have worked with since I started my career. We are using NHibernate, IoC (using Windsor Castle Facility), Separation of Concerns, Generics, Interfaces, etc.
I know exactly what I have broken when I refactor the code within seconds. It allows us to be easily adaptable to changes. The reason I promote testing and all of the different ideas and components above is because I have been on both sides. I have worked without any of this, including automated tests. I know how fast I can respond to changes in my code and how fast I could have responded to changes in the past. We can respond to changes so fast that the bearer of the work for every iteration is the testing.
In a [coding] world of Semper Gumby (Always Flexible), it's good to have code that is very respondent to change.
What is your success story?