Should I unit test the base method is called?

Question

I have two classes

public abstract class BaseClass
{
  public string PropertyA {get; set;}

  public virtual object CopyProperties(BaseClass other)
  {
    other.PropertyA = this.PropertyA;
  }
}

and a class which inherits from it

public class ChildClass : BaseClass
{
  public string PropertyB {get; set;}

  public virtual object CopyProperties(BaseClass other)
  {
    other.PropertyB = this.PropertyB;
    base.CopyProperties(other);
  }
}

Naturally I've unit tested such complex logic!

I have two tests:

Ensure_calling_CloneProperties_copies_PropertyA() Ensure_calling_CloneProperties_copies_PropertyB()

I want to know whether the following test is also required

Ensure_calling_CloneProperties_on_ChildClass_calls_base()

My personal opinion is that we should test the behaviour of CloneProperties on the ChildClass, we need to verify that when we call clone PropertyA and PropertyB are both copied correctly - we do not need (or want) to know how this is achieved. However a colleague disagrees.

Given agile and TDD best practices should I also create the third test?

score 2 · Answer 1 · answered Dec 09 '14 at 17:25

I agree with your opinion. What is important is the behavior of the method, not where its work gets done. Even as regards interaction testing, the "interaction" between a class and its base class isn't "interesting" in terms of system behavior. If (say) the property A copying was done originally in the base class, and you removed that functionality from Base, your property-copying test would detect that failure, so as far as regression, your test suite covers what's important. If the property copying was instead moved from base to child (or vice versa), the test would report no regression - and your system would still be behaving correctly.

score 0 · Answer 2 · edited May 23 '17 at 11:57

I would also suggest to look at possibility to refactor your code so that there is no inheritance. Check this 'inheritance vs composition" thread for more details.

In that case you could inject the current "base class functionality" and ensure your test of ChildClass has no dependency on code in BaseClass

When you write a unit test (which you do in TDD) you test that class only. In your example a verification of the fact that BaseClass.CopyProperties was invoked with a specific parameter is preferable over the check that accesses PropertyA, because if you change base class, child class tests will fail - but they should not.

A further idea might be to decouple BaseClass from ChildClass completely - via an event. BaseClass could subscribe to a specific event of ChildClass and do its stuff, but your test code will be even cleaner now, since all you verify is that ProperyB is set and event is fired.

Should I unit test the base method is called?

2 Answers2