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.
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.
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.
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.
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.
Stop trying to hit me and hit me.
— Morpheus
You can follow @KevlinHenney.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled:

By continuing to use the site, you are consenting to the use of cookies as explained in our Cookie Policy to improve your experience.