There’s a fairly old codebase at our work that was written from a strongly anti-mocking framework POV. The result is god classes, insanely deep levels of coupling and massive, hand-written mocks that are so complicated that they themselves have to be unit tested.

There’s another side of that codebase that’s been written with a heavy, strict mockist POV. The result was an anemic, somewhat overly complicated design and brittle tests that don’t support refactoring.

Here’s the thing, if you don’t pay attention to simplicity and cleanlines then any testing approach that will wind up hiding or encouraging poor design.

In fact, I’m pretty sure I wouldn’t use that technique exactly as described today. It was later pointed out to me that the use of the default mock w/ no behavior specified was a smell of it’s own. This probably deserves a follow-up post on my part… But in short, while the given test may not care to verify anything on one of it’s dependencies, it was very naive of me to assume it was OK to not even describe the mock’s behavior. Now-a-days I create a repository of “working” default mocks (which could be mocks or stubs) and would use one of those instead of an empty default.