The secret world of testing without mocking: domain-driven design, fakes, and other patterns to simplify testing in a microservice architecture
Much has been said about mocks, the controversial, Swiss army knife of test doubles: Don't use them too much (source) (source) Know when to use them at all (source) Don't use them to test implementation detail (source) Don't mock types you don't own (source) Only mock classes when dealing with legacy code (source) Don't mock complex interfaces (source) (source) ...the list goes on. For a tool so easy to misuse, we're using it quite a lot. Mockito is one of the most depended-upon Java libraries in the world . While "mocking" is an abstract concept, for the remainder of this post I'll use the term mock to refer specifically to a mock or stub configured by way of a mocking library like Mockito. Likewise, when I refer to Mockito, I really mean any mocking library; Mockito just stands out because it has a welcoming API and is–no doubt as a consequence–measurably very popular. I was there too once, a frequent Mockito user, perhaps ...