My impression is that most tutorials on mocking and mocking frameworks lead with how to stub code for tests than how to actually use mocks for testing.
Such priming might explain many common misunderstandings around mocking, as well as the parlous state of many mock-based tests.
Such priming might explain many common misunderstandings around mocking, as well as the parlous state of many mock-based tests.
The gratuitous complexity of many mockish tests is testament to the human condition and blind spots in thinking.
Developers invest more time figuring out how to stub problem code, creating tests more complex than the code being tested, than in simplifying the code being tested.
Developers invest more time figuring out how to stub problem code, creating tests more complex than the code being tested, than in simplifying the code being tested.
We've ended up with a culture of injection, with code spending its time shooting up, passing providers, suppliers, factories, etc., leading to much foolish mockery and XML noise.
Code and developers have been cargo-culted into practices that avoid actually writing functionality.
Code and developers have been cargo-culted into practices that avoid actually writing functionality.
In many cases, it is possible to simply replace the provider with the value the code needs, i.e., rather than pass the supplier of the value, pass the value.
This is reversion of control. Simple to write, simple to read, simple to test. Loosely coupled. No injections needed.
This is reversion of control. Simple to write, simple to read, simple to test. Loosely coupled. No injections needed.
In other cases, object internals are exposed because someone picked up the mistaken belief that constructors shouldn't 'new' other objects 
They've taken a poorly articulated idea and perfected it into an art form free of encapsulation and simplicity.

They've taken a poorly articulated idea and perfected it into an art form free of encapsulation and simplicity.
Stop trying to hit me and hit me.
— Morpheus
— Morpheus