I was experimenting with mutation testing using Jester (http://jester.sourceforge.net/) which means I was really, really, really needing something better to do. :-)
Anyway, what mutation testing does for you is modify your code while re-running your junit test. The aim is to find out if a mutation (a code change) results in a test still passing. The goal is to determine test robustness rather than just coverage.
When doing this on a non Spring based app, I found many things that were trivial but escaped the mutation/test cycle. For example, the app had lots of factory methods and lots of config stuff along with extensive exception handling (or masking) and many NPE guards.
In short, I got pretty poor scores on some tests that were really pretty good and had high 90% test coverage (jcoverage rocks). I decided that there was very little value added by tying to improve the jester score.
I decided to try the same on a Spring based app and found out that the results were much better (higher scores) and the reported failures actually were beneficial (I could refactor the code or add additional 'missed' tests).
I didn't initially try to code the Spring app lighter or with fewer checks but it just turned out that way.
Seems like Spring-style coding (IOC + runtime exceptions + simplified / crisper tests) might be more than just feel right.