About Alex Soto

Testing Abstract Classes and Template Method Pattern

From wikipedia “A template method defines the program skeleton of an algorithm. One or more of the algorithm steps can be overridden by subclasses to allow differing behaviors while ensuring that the overarching algorithm is still followed”.

Typically this pattern is composed by two or more classes, one that is an abstract class providing template methods (non-abstract) that have calls to abstract methods implemented by one or more concrete subclasses.

Often template abstract class and concrete implementations reside in the same project, but depending on the scope of the project, these concrete objects will be implemented into another project.

In this post we are going to see how to test template method pattern when concrete classes are implemented on external project, or more general how to test abstract classes.

Let’s see a simple example of template method pattern. Consider a class which is responsible of receiving a vector of integers and calculate the Euclidean norm. These integers could be received from multiple sources, and is left to each project to provide a way to obtain them.

The template class looks like:

public abstract class AbstractCalculator {

 public double euclideanNorm() {

  int[] vector = this.read();

  int total = 0;

  for(int element:vector) {
   total+= (element*element);  
  }

  return Math.sqrt(total);
 }

 public abstract int[] read();
}

Now another project could extend previous class and make an implementation of abstract calculator by providing an implementation of read() method .

public class ConsoleCalculator extends AbstractCalculator {

 public int[] read() {

  int [] data = new int[0];

  Scanner scanner = new Scanner(System.in);

  //data = read requried data from console

  return data; 

 }

}

Developer that has written a concrete implementation will test only read() method, he can “trust” that developer of abstract class has tested non-abstract methods.

But how are we going to write unit tests over calculate method if class is abstract and an implementation of read() method is required?

The first approach could be creating a fake implementation:

public class FakeCalculator extends AbstractCalculator {

 private int[] data;

 public FakeCalculator(int[] data) {
  this.data = data;
 }

 public int[] read() {
  return this.data;
 }

}

This is not a bad approach, but has some disadvantages:

  • Test will be less readable, readers should know the existence of these fake classes and must know exactly what are they doing.
  • As a test writer you will spend time in implementing fake classes, in this case it is simple, but your project could have more than one abstract class without implementation, or even with more than one abstract method.
  • Behaviour of fake classes are “hard-coded”.

A better way is using Mockito to mock only abstract method meanwhile implementation of non-abstract methods are called.

public class WhenCalculatingEuclideanNorm {

 @Test
 public void should_calculate_correctly() {

  AbstractCalculator abstractCalculator = mock(AbstractCalculator.class, Mockito.CALLS_REAL_METHODS);

  doReturn(new int[]{2,2}).when(abstractCalculator).read();
  assertThat(abstractCalculator.euclideanNorm(), is(2.8284271247461903));

 }

 @Test
 public void should_calculate_correctly_with_negative_values() {

  AbstractCalculator abstractCalculator = mock(AbstractCalculator.class, Mockito.CALLS_REAL_METHODS);

  doReturn(new int[]{-2,-2}).when(abstractCalculator).read();
  assertThat(abstractCalculator.euclideanNorm(), is(2.8284271247461903));

 }

}

Mockito simplifies the testing of abstract classes by calling real methods, and only stubbing abstract methods. See that in this case because we are calling real methods by default, instead of using the typical when() then() structure, doReturn schema must be used.

Of course this approach can be only used if your project does not contain a concrete implementation of algorithm or your project will be a part of a 3rd party library on another project. In the other cases the best way of attacking the problem is by testing the implemented class.

Download sourcecode

Reference: Testing Abstract Classes (and Template Method Pattern in Particular) from our JCG partner Alex Soto at the One Jar To Rule Them All blog.

Related Whitepaper:

Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions

Get ready to program in a whole new way!

Functional Programming in Java will help you quickly get on top of the new, essential Java 8 language features and the functional style that will change and improve your code. This short, targeted book will help you make the paradigm shift from the old imperative way to a less error-prone, more elegant, and concise coding style that’s also a breeze to parallelize. You’ll explore the syntax and semantics of lambda expressions, method and constructor references, and functional interfaces. You’ll design and write applications better using the new standards in Java 8 and the JDK.

Get it Now!  

2 Responses to "Testing Abstract Classes and Template Method Pattern"

  1. dharmendar rao says:

    thanks for sharing it.

  2. Mockito rocks! Nevertheless always consider using Delegation instead of Template Method (Inheritance).
    In your example, if AbtrsctaCalculator class was a concreate class with an injectable Reader instance, it should be easier to test:

    public class Calculator {

    private final Reader reader;

    public Calculator(Reader reader){
    this.reader = reader;
    }

    public double euclideanNorm() {

    int[] vector = this.reader.read();

    int total = 0;

    for(int element:vector) {
    total+= (element*element);
    }

    return Math.sqrt(total);
    }
    //no more abstract method to implement}

Leave a Reply


two × = 6



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books
Get tutored by the Geeks! JCG Academy is a fact... Join Now
Hello. Add your message here.