Don't Mock What You Don't Own

Recently i had a discussion with a coworker about the guideline:

Don’t mock what you don’t own

Which, summarized, means you should not mock interfaces or types of external libraries or even your runtime. Still, you will want to mock these dependencies while you test drive your code. As a solution you should create wrappers around these external classes and mock the wrapper.

public class Wrapper {
  private ExternalObject wrappedObject;

  public Wrapper() {
    wrappedObject = new ExternalObject();

  public void doSomething() {

This is usually first met with uncertainty. Isn’t the primary use case of mocks to fake classes that talk to databases or the network? Well, lets look at the benefits of wrapping these dependencies:

To make sure your code will actually store something in the database, not just verify that the method to store something is called, you will make use of integration tests which will test the boundaries between your wrappers and the external library. See Hexagonal Architecture.