Question

I’ve got a bunch of methods in my application service layer that are doing things like this:

public void Execute(PlaceOrderOnHoldCommand command)
{
    var order = _repository.Load(command.OrderId);
    order.PlaceOnHold();
    _repository.Save(order);
}

And at present, I have a bunch of unit tests like this:

[Test]
public void PlaceOrderOnHold_LoadsOrderFromRepository()
{
    var repository = new Mock<IOrderRepository>();
    const int orderId = 1;
    var order = new Mock<IOrder>();
    repository.Setup(r => r.Load(orderId)).Returns(order.Object);

    var command = new PlaceOrderOnHoldCommand(orderId);
    var service = new OrderService(repository.Object);
    service.Execute(command);

    repository.Verify(r => r.Load(It.Is<int>(x => x == orderId)), Times.Exactly(1));
}

[Test]
public void PlaceOrderOnHold_CallsPlaceOnHold()
{
            /* blah blah */
}

[Test]
public void PlaceOrderOnHold_SavesOrderToRepository()
{
            /* blah blah */
}

It seems to be debatable whether these unit tests add value that’s worth the effort. I’m quite sure that the application service layer should be integration tested, though.

Should the application service layer be tested to this level of granularity, or are integration tests sufficient?

Answer 1

Exactly: it’s debatable! It’s really good that you are weighing the expense/effort of writing and maintaining your test against the value it will bring you – and that’s exactly the consideration you should make for every test you write. Often I see tests written for the sake of testing and thereby only adding ballast to the code base.

As a guideline I usually take that I want a full integration test of every important successful scenario/use case. Other tests I’ll write are for parts of the code that are likely to break with future changes, or have broken in the past. And that is definitely not all code. That’s where your judgement and insight in the system and requirements comes into play.

Assuming that you have an (integration) test for service.Execute(placeOrderOnHoldCommand), I’m not really sure if it adds value to test if the service loads an order from the repository exactly once. But it could be! For instance when your service previously had a nasty bug that would hit the repository ten times for a single order, causing performance issues (just making it up). In that case, I’d rename the test to PlaceOrderOnHold_LoadsOrderFromRepositoryExactlyOnce().

So for each and every test you have to decide for yourself … hope that helps.

Notes:

1. The tests you show can be perfectly valid and look well written.

2. Your test sequence methods seems to be inspired on the way the Execute(...) method is currently implemented. When you structure your test this way, it could be that you are tying yourself to a specific implementation. This way, tests can actually make it harder to change – make sure you’re only testing the important external behavior of your class.