Question

Assume we have an Order class with a method called Approve. When this method is called, it checks certain conditions and either puts the Order in the state of Approved or throws an exception. In the service layer, we’ve got something like this:

var order = _repository.Single(o => o.ID == orderID);
order.Approve();
_context.SaveChanges(); // or _session.SaveChanges(); 

There are 2 ways to test this method and I’d like to hear your insight on this:

Solution 1: Stub the repository to return an Order object. Then assert the Order is in the state of “Approved”.

Solution 2: Stub the repository to return a Mock Order object. Assert that Approve() method was called.

Solution 1 is easier and I personally favor state-based testing to interaction-based testing, as the latter can target implementation details and should be avoided. However, I believe testing that the given Order is in the state of Approved is not the concern of this service method. I think we need a separate test method for the Order class to test whether an exception is thrown or the Order’s state is changed to Approved.

Solution 2 may sound logical as we are delegating the responsibility of Approving an Order to the Order class itself. So perhaps we need 2 tests for this service method: One to ensure it delegates the task of Approving an Order to the Order class and one to ensure it saves the changes.

What’s your insight on this? Which solution do you prefer?

Cheers

Answer 1

Unit tests are to test whether the observed behavior is conforming to expectations/specification.

The answer to your question boils down to what you consider “expected behavior” in this case: a) if the expected behavior is that the Order is in approved state after calling the service method, then test the state; b) if the expected behavior is that the approve action is delegated, then test the method call.

You will need to test the Order object’s behavior as well (so that calling Approve() changes the state to approved) in either case.

The second solution plays well as it decouples the behavior of the two objects, but if there are more than one ways that the order can be in approved state (and that’s what you are testing — case a)), then you limit the accepted behavior needlessly.

Also, I would create a separate test for testing the saving part, if that is not essential to the approval part