How should you look at unit testing protected members used by the abstract base class?

Question

I have the following class(es) that I want to write unit tests for:

public abstract class BaseClass
{
    public bool IsFooBar(Order order)
    {
        return order.IsNew && IsFooBarOverride(order);
    }

    protected abstract IsFooBarOverride(Order order);
}

public class SimpleDerivedClass : BaseClass
{
    protected override bool IsFooBarOverride(Order order)
    {
        // Return if the order is with a credit card.
    }
}

public class ComplexDerivedClass : BaseClass
{
    protected override bool IsFooBarOverride(Order order)
    {
        // Return a very complex statement
        // If the order is for a new customer
        // in New York, with an order amount of $500 or more
        // and has at opted for email subscriptions.
    }
}

The problem I am running into is that my derived classes contain the majority of my logic for determining the return value of IsFooBar(Order order). I want to test this logic to ensure it is proper. I was under the impression that you should only test the public API of a class, which is IsFooBar(Order order), which belongs to the base class.

• Should I redesign my class structure by marking IsFooBar virtual and hope that other developers on the team use base.IsFooBar(order) as part of their return statement?

• Should I leave my class structure in tact and test variations of the IsFooBar(Order order) method per derived class as a way to test the logic in the protected class?

Answer 1

Considering your doubts, I would argue that the choice of solving this with inheritance might be the wrong approach.

Perhaps composition would be more appropriate in this case? It is hard to tell without knowing the requirements.

To answer the question, as long as the template method is the way to go, test per derived class.

Answer 2

Depending on your unit test framework, you can write an abstract base test class that will contain assertions about what your abstract production class should do.

All subclasses of that base test class will automatically run these "parent" tests as well as any other tests related to their specific concrete System Under Test.

To generate the System Under Test, you can resort to a Factory method (or Factory Property) pattern.

Example with NUnit :

[TestFixture]
public abstract class BaseTest
{
    protected abstract BaseClass Sut { get; }

    [Test]
    public void An_old__order_should_never_be_FooBar()
    {
        var result = Sut.IsFooBar(new Order {IsNew = false});
        Assert.IsFalse(result, "An old Order should never be FooBar no matter the concrete implementation");
    }
}

public class SimpleDerivedClassTest : BaseTest
{
    protected override BaseClass Sut { get { return new SimpleDerivedClass(); } }

    // Your other, SimpleDerived-specific tests here
}

public class ComplexDerivedClassTest : BaseTest
{
    protected override BaseClass Sut { get { return new ComplexDerivedClass(); } }

    // Your other, ComplexDerived-specific tests here
}

As a side note, in the particular example you chose it might not seem so easy to determine what assertions will hold in all circumstances and should therefore go in the base test class. But it is in fact quite trivial (all !IsNew Orders should be !FooBar...)

Answer 3

I was under the impression that you should only test the public API of a class, which is IsFooBar(Order order), which belongs to the base class.

Not quite.

That method is protected and so is only available to subclasses.
OK, it's accessible outside the class (to a degree), but it's certainly not "public".

... my derived classes contain the majority of my logic for determining the return value of IsFooBar(Order order). I want to test this logic to ensure it is proper.

Since the implementation of these overridden methods is what you need to test, then write tests for the concrete classes (I, for one, don't know how to test an instance method on an abstract class, because you can't instantiate that class so, from a purely practical standpoint, you have to work with (i.e. test) the subclasses.

If the bulk of the code were in [abstract] base class implementation of a given method, then you might consider writing a [concrete] subclass purely for testing purposes.