How to Test Abstract Class in Java with Junit

How to test abstract class in Java with JUnit?

If you have no concrete implementations of the class and the methods aren't static whats the point of testing them? If you have a concrete class then you'll be testing those methods as part of the concrete class's public API.

I know what you are thinking "I don't want to test these methods over and over thats the reason I created the abstract class", but my counter argument to that is that the point of unit tests is to allow developers to make changes, run the tests, and analyze the results. Part of those changes could include overriding your abstract class's methods, both protected and public, which could result in fundamental behavioral changes. Depending on the nature of those changes it could affect how your application runs in unexpected, possibly negative ways. If you have a good unit testing suite problems arising from these types changes should be apparent at development time.

How to test an abstract superclass in Java

First let me say, that your approach is absolutely viable. I am just sharing my own way of doing it, because it spares copy pasting tests common between different implementations.

I don't specifically test abstract classes. Because we are testing functionality and it can be overridden in subclasses. I'll use your Person class for this setup, but i will simplify it a bit.

public abstract class Person {

    private String name;
    private String email;

    public Person(String name, String email) {
        this.setName(name);
        this.email = email;
    }

    public String getName() {
        return this.name;
    }

    public void setName(String name) {
        if (name == null || name.isEmpty()) {
            throw new IllegalArgumentException("missing name");
        }
        this.name = name;
    }

    public String getEmail() {
        return this.email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

Student

public class Student extends Person {

    private String university;

    public Student(String name, String email, String university) {
        super(name, email);
        this.university = university;
    }

    public String getUniversity() {
        return this.university;
    }

    public void setUniversity(String university) {
        this.university = university;
    }
}

Child

public class Child extends Person {

    private String school;

    public Child(String name, String email, String school) {
        super(name, email);
        this.school = school;
    }

    public String getSchool() {
        return this.school;
    }

    public void setSchool(String school) {
        this.school = school;
    }

    @Override
    public String getName() {
        return "I am not saying!";
    }
}

So we have the abstract Person, a Student, whose specific thing is a university and a Child. Having a school is what is specific for the child, but it also changes the behaviour of getName(), it does not disclose its name. This might be desired, but for this example we'll assume it was incorrect to override getName() like this.

When dealing with abstract classes i make an abstract test class, which holds common setup and tests for common functionality provided by the abstract class - Person in this case.

public abstract class PersonBaseTests {

    protected static final String EXPECTED_NAME = "George";

    private Person person;

    @BeforeEach
    public void setUp() {
        this.person = getConcretePersonImplementation();
    }

    /**
     * @return new instance of non-abstract class extending person
     */
    protected abstract Person getConcretePersonImplementation();

    //common tests
    @Test
    public void testGetName_ShouldReturnCorrectValue() {
        assertEquals(EXPECTED_NAME, this.person.getName());
    }

    @Test
    public void testConstructor_ShouldThrowIllegalArgumentExceptionOnMissingName() {
        Executable invalidConstructorInvocation = getConstructorExecutableWithMissingName();
        IllegalArgumentException exception = assertThrows(IllegalArgumentException.class, invalidConstructorInvocation);
        assertEquals("missing name", exception.getMessage());
    }

    protected abstract Executable getConstructorExecutableWithMissingName();

    //other common tests
}

The test classes extending the base must provide the concrete implementation to be tested. They will also inherit the tests, so you don't need to write them again. If you still have not learned about interfaces, lambdas and stuff like that, you can ignore the constructor exception test and everything related to it, and focus on getName() test. It tests that the getter correctly returns the name of the Person. This will obviously fail for Child, but that's the idea. You can add tests for getting and setting email, phone, etc.

So, student tests

public class StudentTests extends PersonBaseTests {

    @Override
    protected Person getConcretePersonImplementation() {
        return new Student(PersonBaseTests.EXPECTED_NAME, "mail", "Cambridge");
    }

    @Override
    protected Executable getConstructorExecutableWithMissingName() {
        //setup invocation which will actually fail
        return new StudentConstructorExecutable(null, "email@email.email", "Stanford");
    }

    private static final class StudentConstructorExecutable implements Executable {

        private final String name;
        private final String email;
        private final String university;

        private StudentConstructorExecutable(String name, String email, String university) {
            this.name = name;
            this.email = email;
            this.university = university;
        }

        @Override
        public void execute() throws Throwable {
            //this will invoke the constructor with values from fields
            new Student(this.name, this.email, this.university);
        }
    }

    //write tests specific for student class
    //getUniversity() tests for example
}

Again, ignore the Executable and everything related to the constructor test, if you have not learned it yet. Student tests provide concreete instance of Student for the common inherited tests, and you can write additional tests for specific functionality - get/set university.

Child tests

public class ChildTests extends PersonBaseTests {

    @Override
    protected Person getConcretePersonImplementation() {
        return new Child(PersonBaseTests.EXPECTED_NAME, "", "some school");
    }

    @Override
    protected Executable getConstructorExecutableWithMissingName() {
        //this can be ignored
        return () -> new Child(null, "", "");
    }

    //write tests specific for child class
    //getSchool() tests for example
}

Again, a concrete instance is provided for the common tests - this time of type Child. And you can add tests for any additional functionality provided by Child class - get and set school in this example. Then you can write more test classes for every additional subclass of Person.

Like this you keep common tests at one place and every concrete implementation of abstract class you write is completely tested, without test duplication. About the failing test, if the change in behaviour of getName() is intentional, you can just override it in ChildTests to take that into account. If it is not intentional, you know, that Student.getName() is correct, while Child.getName() is not, but you wrote the test only once.

How to unit test abstract classes: extend with stubs?

There are two ways in which abstract base classes are used.

1. You are specializing your abstract object, but all clients will use the derived class through its base interface.

2. You are using an abstract base class to factor out duplication within objects in your design, and clients use the concrete implementations through their own interfaces.!

---

Solution For 1 - Strategy Pattern

If you have the first situation, then you actually have an interface defined by the virtual methods in the abstract class that your derived classes are implementing.

You should consider making this a real interface, changing your abstract class to be concrete, and take an instance of this interface in its constructor. Your derived classes then become implementations of this new interface.

This means you can now test your previously abstract class using a mock instance of the new interface, and each new implementation through the now public interface. Everything is simple and testable.

---

Solution For 2

If you have the second situation, then your abstract class is working as a helper class.

Take a look at the functionality it contains. See if any of it can be pushed onto the objects that are being manipulated to minimize this duplication. If you still have anything left, look at making it a helper class that your concrete implementation take in their constructor and remove their base class.

This again leads to concrete classes that are simple and easily testable.

---

As a Rule

Favor complex network of simple objects over a simple network of complex objects.

The key to extensible testable code is small building blocks and independent wiring.

---

Updated : How to handle mixtures of both?

It is possible to have a base class performing both of these roles... ie: it has a public interface, and has protected helper methods. If this is the case, then you can factor out the helper methods into one class (scenario2) and convert the inheritance tree into a strategy pattern.

If you find you have some methods your base class implements directly and other are virtual, then you can still convert the inheritance tree into a strategy pattern, but I would also take it as a good indicator that the responsibilities are not correctly aligned, and may need refactoring.

---

Update 2 : Abstract Classes as a stepping stone (2014/06/12)

I had a situation the other day where I used abstract, so I'd like to explore why.

We have a standard format for our configuration files. This particular tool has 3 configuration files all in that format. I wanted a strongly typed class for each setting file so, through dependency injection, a class could ask for the settings it cared about.

I implemented this by having an abstract base class that knows how to parse the settings files formats and derived classes that exposed those same methods, but encapsulated the location of the settings file.

I could have written a "SettingsFileParser" that the 3 classes wrapped, and then delegated through to the base class to expose the data access methods. I chose not to do this yet as it would lead to 3 derived classes with more delegation code in them than anything else.

However... as this code evolves and the consumers of each of these settings classes become clearer. Each settings users will ask for some settings and transform them in some way (as settings are text they may wrap them in objects of convert them to numbers etc.). As this happens I will start to extract this logic into data manipulation methods and push them back onto the strongly typed settings classes. This will lead to a higher level interface for each set of settings, that is eventually no longer aware it's dealing with 'settings'.

At this point the strongly typed settings classes will no longer need the "getter" methods that expose the underlying 'settings' implementation.

At that point I would no longer want their public interface to include the settings accessor methods; so I will change this class to encapsulate a settings parser class instead of derive from it.

The Abstract class is therefore: a way for me to avoid delegation code at the moment, and a marker in the code to remind me to change the design later. I may never get to it, so it may live a good while... only the code can tell.

I find this to be true with any rule... like "no static methods" or "no private methods". They indicate a smell in the code... and that's good. It keeps you looking for the abstraction that you have missed... and lets you carry on providing value to your customer in the mean time.

I imagine rules like this one defining a landscape, where maintainable code lives in the valleys. As you add new behaviour, it's like rain landing on your code. Initially you put it wherever it lands.. then you refactor to allow the forces of good design to push the behaviour around until it all ends up in the valleys.

Java - How to test the non-abstract methods of an abstract class?

You wouldn't be able to create an instance of just SomeAbstractClass, no - but you could create an anonymous subclass:

private SomeAbstractClass sac = new SomeAbstractClass() {};

You may well want to create a concrete subclass just for the sake of testing though - so that any time you do add abstract methods, you just need to put them there.

While I suspect you could use a mocking framework for this, I suspect it would add more complexity for little benefit, unless you need to check under what situations the abstract methods are called. (Mocks are great for interaction testing, but can be brittle for other purposes.) It could easily make for more confusing error messages (due to the infrastructure involved) as well.

Test abstract class which extends another class

Mockito can't mock abstract classes. But you can have a subclass for your test purpose which implement your class B and then spy on it.

@RunWith(MockitoJUnitRunner.class)
public class BTest {

    @InjectMocks
    @Spy
    private FakeB b;

    @Test
    public void testSomething() {
        when(b.convert(any())).thenReturn(something);
    }

    public static class FakeB extends B {
        protected Object convert(Object someobject) {
            return null;
        }  
    }
}

With this approach you can easily mock your abstract methods and test non-abstract ones in your abstract classes. Of course the downside is that you have to crate a fake test classes that subtypes your abstract classes. But I think it shouldn't be a big issue.

Unit testing methods implemented in Abstract Class without specific implementation

The shortest answer is that you are approaching the problem from the wrong end. Start with something simple that works, then you'll be able to test it. Add abstractions as you develop the program, don't start from abstractions, because you won't know what you will really need before you do it.

Also if you have utility methods that don't actually depend on your Player implementation then those clearly shouldn't be part of Player class.

---

Related Topics