Is the use of Auto Mocking containers good or bad practice?

Question

I've recently been working on a project that has started to get fairly dependency heavy and have been exploring the idea of using an AutoMocking container to clean up my tests a bit and make them less brittle.

I've heard arguments against using them by TDD/BDD purists, stating things like: It isn't immediately obvious which dependencies are required by the test subject, or you can add dependencies that you don't really need. Neither sounds like a particularly strong argument against using them.

From my perspective, introducing one would allow me to refactor as required, removing and introducing dependencies in line with business requirements, without constantly having to return to the tests and introduce new mocks/stubs just to get the code to compile.

Is AutoMocking considered to be a good/bad practice? Are there specific situations when it should be or should not be used?

Answer 1

As with any tool or process, there are correct times and incorrect times to use them. Nothing is a silver bullet. You have to ask yourself "will this help me get my job done?" And at the end of our day, our job is to provide the most business value we can for the buck.
When doing greenfield development, automocking isn't as helpful. Everything is being developed from scratch, and TDD/BDD techniques with "traditional" mocking works great. Theoretically, the dependencies aren't changing that drastically, and when they are, it's probably good to know when you are breaking things.

When in maintenance mode (or dealing with a legacy codebase), automocking can prove to be extremely beneficial. For example, you are tasked with cleaning up technical debt. This will probably involve a lot of refactoring, and being able to isolate your tests from these changes is a huge timesaver. Keep in mind that if your code has a lot of dependencies, it's probably breaking SOLID and SOC, and you will (or at least should) have many tests that don't utilize all of the dependencies. So automocking in this case is extremely beneficial. Of course there are many other examples where it helps as well.

As with any tool, you have to make sure that it doesn't become a crutch. Leveraging automocking so you can change interfaces and apis willy-nilly is obviously an anti-pattern. But when used correctly, I have found it to be a huge benefit to our project teams.

It just requires critical thought and application in the correct scenarios.

Answer 2

Manually wiring your dependencies (and keep in mind in unit tests your dependencies should be for a very small number of subject objects(one)) lets you know when you have a smell - This class is too damn big and should be cut down. That said I don't think auto mocking is bad, but like every tool should be used with caution.

Answer 3

Auto mocking starts to be useful just in that point where the dependencies start to smell. Both the answer by Skimedic and the comment by levelnis point in that same direction. So this practice should be avoided in general, except in the cases where you cannot get rid of legacy/tech debt. Even in some of those cases I reckon it may be better to act like auto mocking does not exist, and let the diminished velocity of the team be another reason to force management to consider that some refactor is in order; or, if it is some unavoidable legacy, then program your own fake builders; the added complexity of the test will be a better marker of a "danger zone" than simply using auto mocking and having apparently simple tests.

And, IMO, you should not use it at all with new code.