Powermocking and OOP

Encapsulation helps us to define boundaries of data and behavior within a class, though there are mocking frameworks which bend the rules of this protection. But, if you consider, is it all right to drill down through this protection layer by leveraging the reflection API and mock private methods even within unit tests? An idealistic object oriented programmer would claim that it is basically a violation against object oriented programming principles. In my opinion, it depends on the context and situation in which you attempt to violate the rules of the paradigm at the first sight. However, the mocking frameworks like Powermock might save the day, if you need to mock the call to a static factory method, of which factory is required to be set up first in order to create an instance.

Let’s think about the following scenario:

public class PizzaFactory {
       private final int season; // 1 => Winter, 2 => Spring, 3 => Summer, ...
       public PizzaFactory() {
       	      this.season = getCurrentSeason(System.getCurrentTimeInMillis());
       }

       public static Pizza makePizza() {
       	      return new Pizza(season);
       }
}

The

1

PizzaFactory

1

makePizza

Let’s have a look at the second version of the factory:

public class PizzaFactory {
       private final int season; // 1 => Winter, 2 => Spring, 3 => Summer, ...
       private PizzaFactory(int season) {
    	      this.season = season;
       }
       public static PizzaFactory of(int season) {
       	      return new PizzaFactory(season);
       }
       public static Pizza makePizza() {
	      return new Pizza(season);
       }
}

Now, we provide the season variable from outside of the factory, so we don’t need to mock the method call

1

makePizza()

@Test
public void testSummerPizza() {
       Pizza summerPizza = PizzaFactory.of(Season.SUMMER).makePizza();
       Result result = actualInstanceUnderTest.eat(summerPizza);
       assertThat(result.getStatus(), Stomach.FULL)
}

With a simple touch, you see how we got rid of mocking in this case.

Conclusion

I do not mind that refactoring the design is a silver bullet and will always discard the need of mocking in every case. However, in most cases smart design decisions would help you avoiding using mocking frameworks. If you involve testing motivation in early phases of development, you can detect such workaround-like tendencies as fast as possible what in turn gives you a chance to reconsider the design before it is too late.