I’ve been working with a client (I’m a contractor) that subscribes to this principle fairly rigorously. Though I don’t have full visibility as to how it’s working, in my experience, they’ve spent more time in unit tests than they have in adding functionality, which isn’t necessarily a bad thing. They aim for 80% coverage which is in line with the 70% standard you emailed about before and I think that is a very good idea, since, in their case, they use unit tests not only for coverage and regression, but as a method of communicating API changes. You won’t really get an email or notification about an API change (unless you sit there watching SVN commits religiously) until your code breaks with the latest svn update. It’s an interesting approach, and can be a bit harsh, but if you have good code coverage, it’ll ensure that all your interactions with that API are updated.

Now automated UI testing is another animal all together. I think it’s hard to maintain automated scripts when a UI is constantly in flux, but the concept of code coverage to highlight incompatibility with a changing API could be applied for some basic automated UI testing to the same effect that a business layer might make use of such test.