Should We Use Mocks?

Home -> User Guide -> General User Guide -> Mocks and Stubs ->

Proponents of sound software engineering practices often remind us excessive use of mocks in test cases may be an indicator the code under test needs to be refactored. In particular, the code under test is likely to violate the principle of Separation of Concerns.

If you want more background information about this topic, Vasily Zukanov provides a good summary of the ongoing debate about mocks in his 2020 article, To Mock, or Not to Mock, That is the Question.

Cobol-check is mainly aimed at developers who must support existing Cobol business applications in an IBM mainframe environment. In that context, we are likely to find very large procedural programs designed monolithically. As a practical matter, there will be many situations in which we have no choice but to mock or stub resources that are outside the immediate scope of a unit-level check.

When our test cases seem to be heavy with mocks, we may take it as a cue to refactor the code under test. We should go ahead and do so if we can, but refactoring may not always be feasible due to limitations in available tooling, time, or organizational constraints.

Many of those who argue against the use of mocks live in a world where refactoring is well-supported by IDEs and code bases are not so very old that they may contain hidden business logic that is important to the enterprise. These factors are quite different in the mainframe world. So, we think this is not the best context for arguing against the use of mocks. Use mocks as needed, and refactor when you can.