Verifying Method Calls on Internally Created Objects with Mockito: Dependency Injection and Test-Driven Design

Problem Context and Challenges

In unit testing practice, developers frequently encounter scenarios where they need to verify that methods are correctly called on objects created within other methods. Consider this typical code example:

public class Foo {
    public void foo() {
        Bar bar = new Bar();
        bar.someMethod();
    }
}

The tester wants to use Mockito to verify that someMethod is called exactly once after executing the foo method:

verify(bar, times(1)).someMethod();

The core challenge here is that the Bar object is instantiated inside the foo method, making it inaccessible to test code for direct verification.

Dependency Injection Solution

Dependency injection serves as the classic pattern for solving such testing challenges. By transferring object creation control from inside methods to external sources, test code gains the ability to inject mock objects.

The refactored Foo class employs constructor injection:

public class Foo {
    private Bar bar;
    
    public Foo(Bar bar) {
        this.bar = bar;
    }
    
    public void foo() {
        bar.someMethod();
    }
}

The corresponding test code becomes straightforward:

@Test
public void testFoo() {
    Bar mockBar = mock(Bar.class);
    Foo foo = new Foo(mockBar);
    
    foo.foo();
    
    verify(mockBar, times(1)).someMethod();
}

Advanced Factory Pattern Application

When more flexible object creation control is required, the factory pattern offers a more elegant solution. This approach proves particularly useful for scenarios involving complex object creation logic or dynamic configuration needs.

Define the factory interface and implementation:

public interface BarFactory {
    Bar createBar();
}

public class Foo {
    private BarFactory barFactory;
    
    public Foo(BarFactory factory) {
        this.barFactory = factory;
    }
    
    public void foo() {
        Bar bar = this.barFactory.createBar();
        bar.someMethod();
    }
}

Test code implements the factory interface using anonymous inner classes:

@Test
public void testDoFoo() {
    Bar bar = mock(Bar.class);
    BarFactory myFactory = new BarFactory() {
        public Bar createBar() { return bar; }
    };
    
    Foo foo = new Foo(myFactory);
    foo.foo();
    
    verify(bar, times(1)).someMethod();
}

Value of Test-Driven Design

This case perfectly demonstrates how test-driven development drives code design improvements. The initial code design presented testing difficulties, but through TDD practice, we were compelled to reconsider the code structure, ultimately achieving a more loosely coupled and testable design.

Dependency injection not only resolves testing issues but also delivers additional benefits: enhanced code maintainability, reduced coupling between classes, and improved extensibility and modifiability. This design pattern aligns with object-oriented design principles, particularly the dependency inversion principle.

Alternative Approach Comparison

Beyond dependency injection, other testing methods exist, each with distinct advantages and disadvantages:

The PowerMockito approach intercepts constructor calls through bytecode manipulation, enabling testing without modifying production code. However, this method increases testing complexity, may mask design problems, and faces compatibility issues with certain testing frameworks.

The Spy approach monitors real object behavior through partial mocking but still encounters limitations when dealing with internally created objects and may introduce tight coupling between test and production code.

Best Practices Summary

Based on practical project experience, we recommend the following best practices: prioritize refactoring code using dependency injection patterns, as this not only addresses testing concerns but also enhances code quality. Reserve tools like PowerMockito for special circumstances where production code modification is impossible.

Test code should remain clear and concise, avoiding overly complex mocking and verification logic. Well-designed tests should provide rapid feedback on code changes, offering reliable support for continuous integration and refactoring efforts.