We've just had a posting to the jMock user list that included the following:
I was involved in a project recently where JMock was used quite heavily. Looking back, here's what I found:
- The unit tests where at times unreadable (no idea what they were doing).
- Some tests classes would reach 500 lines in addition to inheriting an abstract class which also would have up to 500 lines.
- Refactoring would lead to massive changes in test code.
I've seen this failure mode on another project I've been helping with, so I think there might be a common pattern.
I don't think any unit test code should get that large, except for unusual circumstances. Unit tests are supposed to focus on at most a few classes and shouldn't need a large amount of set up. What I saw on the other project was enormous amounts of preparation and positioning to get the objects into a state where the expected feature could be exercised. Of course it's hard to understand the point of a test when there's just so much code. If you see this pattern, then I'd suggest that the code (or at least the test code) needs breaking up a bit. On the other hand, integration and acceptance tests that happen to be written using a unit test framework might well be larger.
One thing I need to explore is whether the naive use of interaction-testing is particularly susceptible to this failing, or whether it happens all the time and we're the only ones who get complained to. I am, however, convinced that the emphasis on mainly using Mocks to substitute external systems (some of which I perpetrated myself in the early days) is a deeply bad idea which pushes teams towards the sort of problem described here.