Inversion of dependencies is important for several reasons, among which are that inverted dependencies increase flexibility, decrease fragility, and help the code to be potentially reused.

Inversion of dependencies allows for a plugin type architecture. By defining a contract of interaction, a module can determine how it wants to interact with dependencies. Then the dependencies depend on that contract.

Because the top-level module has no outgoing dependencies, it can be deployed independently. Deploying a piece of an application independently almost never happens, but having an independently deployable library has the tremendous benefit of not needing to be recompiled when a dependency changes.

In normal development, the dependencies fluctuate a lot more than the higher-level modules. This fluctuation causes the need to recompile. When your application dependencies flow downward, a dependency recompile also triggers a recompile of the dependent library. So, in effect, changing a utility helper class in a tiny, but common library will trigger a recompile of your entire application.

If you are inverting your dependencies, however, a change like this will only trigger a recompile of the utility helper library and the application library. It will not trigger a recompile of every library between.

That does it for the SOLID principles. Please keep them in mind if you choose to use a mocking framework. Make sure you don't allow the mocking framework to trick you into building a rigid, fragile, immobile system.