Unit testing - one test is partly a "superset" of another, is this wrong?

Question

Wasn't sure how to phrase that title, sorry!

I've just come across this in our code base, and was wondering what the consensus was about how to unit test it:

C# (-ish, sorry, this is paraphrased from memory)

class DateCalculator
{
   public static DateTime CalculateLeadTime(DateTime deliveryDate)
   {
      //return the result of some determinate calculation involving deliveryDate
   }
}

//New example
class OrderController
{
    public ActionResult GetLeadTime(WidgetOrder order)
    {
        var leadTime = DateCalculator.CalculateLeadTime(order.GetDeliveryDate() );
        return Json(leadTime.Value.Date.ToString("dd/MM/yyyy") );
    }
}

//Old, incorrect example
class OrderService
{
   public DateTime GetLeadTime(WidgetOrder order)
   {
      return DateCalculator.CalculateLeadTime(order.GetDeliveryDate() );
   }
}

We've then got two unit tests, one to verify that CalculateLeadTime works (this is very easy, you can put in several test values and predict what comes out), and one that GetLeadtime works (still easy, but...). My question is: what would you test here, and where?

It makes sense to me to test CalculateLeadTime in isolation, because it could be a complicated calculation, and it's already a nice small predictable unit. But would you then go on to test some of the same stuff (maybe a single representative input and output?) in your GetLeadTime method? Or would you simply test that any DateTime value is returned, and assume that the calculation is correct because you're testing that somewhere else? Or would you not test the Calculate method on its own, because you know that you're going to test it when you use it, and you don't like the duplication?

EDIT: to muddy the waters a bit, I can see the code now, and rather than a Service, the calling class is an MVC Controller, and the Action under scrutiny is an AJAX method so returns the result of the calculation wrapped in JSON. The current test verifies that JSON is returned, but not the contents of it. Does this change anything?

Answer 1

You're making a big mistake when you put assumptions into your unit tests about how the unit is implemented.

Consider what would happen were the implementation of OrderService to change so that it no longer used DateCalculator (or, more generally, if you wanted to test a different implementation with the same unit tests). Your unit tests for OrderService would no longer be able to catch most of the potential errors.

While it is true that you can use white-box information to tailor unit tests to code, the unit tests should not be designed to make assumptions about how the code works. So, yes: I would absolutely write tests that may end up running the same code, because code isn't written in stone and I don't want my tests to be concretely coupled to the code it's supposed to be checking.

Answer 2

Ideally you should change your design a little bit and decouple OrderService from DateCalculator.CalculateLeadTime by using dependency injection:

class OrderService
{
   Func<DateTime,WidgetOrder> _calculateLeadTime;

   public OrderService(Func<DateTime,WidgetOrder> calculateLeadTime)
   {
       _calculateLeadTime=calculateLeadTime;
   }

   public DateTime GetLeadTime(WidgetOrder order)
   {
      return _calculateLeadTime(order.GetDeliveryDate() );
   }
}

Now its easy to unit test OrderService in isolation: instead of DateCalculator.CalculateLeadTime, pass a mock function through the constructor for your test and check if it is correctly called from the GetLeadTime. This changes the situation so the meaningful tests for OrderService are not a superset of the tests for DateCalculator any more.

Of course, you may add an integration test to your test suite, which checks if OrderService.GetLeadTime returns the expected value when it is constructed with the intended DateCalculator.CalculateLeadTime function. But typically for those integration tests you need only a smaller range of test cases as for your unit tests. Since you have tests for the individual behaviour of both units, you already trust their core functionality and you need only make sure they both work together as intended.

In the current simplistic example, it is debatable if the situation does really need all three kinds of tests, but in general (assumed some more complex functions in your real world scenario), this typically pays off.