> For the complete documentation index, see [llms.txt](https://raviram.gitbook.io/unit-testing/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://raviram.gitbook.io/unit-testing/mocking-1/shortcomings.md).

# Shortcomings

## The shortcomings of mocking frameworks

While mocking frameworks are very useful during TDD in that they simplify unit testing through the use of mock objects, they, however, have some limitations and downsides that can impact the design of the code

### Interface explosion

The architecture of the majority of the mocking frameworks necessitates that interfaces should be created in order to mock objects.

In essence, you cannot mock a class directly; it has to be through the interface implemented by the class.

In an attempt to mock dependencies during unit testing, an interface is created for each object or dependency to be mocked, even if the interface is not required to use the dependency in production code.

This results in the creation of too many interfaces, a condition known as interface explosion

### Extra complexity

Most mocking frameworks use **reflection** or create *proxies* to invoke the methods and create the mocks required in unit tests. This process is **slow** and adds overhead to the unit testing process.

### Mock explosion

With the availability of several mocking frameworks, it is easier to get familiar with mocking concepts and create mocks for unit testing. However, a developer can start to over-mock!

> When all you have is a Hammer, everything looks like a Nail!
>
> -Abraham Maslow