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?
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.