Do I need to write a unit test for a method within service class that only calls a method within repository class?

Question

Example

I have a repository class (DAL):

public class MyRepository : IMyRepository
{
    public void Delete(int itemId)
    {
        // creates a concrete EF context class
        // deletes the object by calling context.DeleteObject()
    }

    // other methods
}

I also have a service class (BLL):

public class MyService
{
    private IMyRepository localRepository;

    public MyService(IMyRepository instance)
    {
        this.localRepository = instance;
    }

    public void Delete(int itemId)
    {
        instance.Delete(itemId);
    }

    // other methods
}

Creating a unit test for MyRepository would take much more time than implementing it, because I would have to mock Entity Framework context.

But creating a unit test for MyService seems nonsense, because it only calls into Repository. All I could check is to verify if it did actually call repository Delete method.

Question

How would you suggest to unit test these pair of Delete methods. Both? One? None? And what would you test?

Answer 1

Yes, I would definitely write a unit test for the Service Layer. The reason for this is because, you're not just testing that your implementation works now, but you're also testing that it will continue to work in the future.

This is a vital concept to understand. If someone comes along later on and changes your ServiceLayer, and there's no unit test, how can you verify that the functionality continues to work?

I would also write tests for your DAL, but I would put those in a separate assembly called DataTests or something. The purpose here is to isolate your concerns across assemblies. Unit Tests shouldn't be concerned with your DAL, really.

Answer 2

Yes, both.

IMyRepository mock = ...;
// create Delete(int) expectation

MyService service = new MyService(mock);
service.Delete(100);

// Verify expectations

Your Delete method right now might only call the Delete method on the repository, but that doesn't mean it always will. You want to have unit tests for this partly to verify it behaves correctly and partly as way of defining your specifications of how the repository is to work.

You also aught to have a test that verifies that the constructor will throw an exception if the repository is null. You might also have other validation to do here in this method such as non-negative ID's, or non-zero id. Maybe that doesn't happen here, make it part of the specifications by creating tests that verify the expected behaviors.

They seem trivial but I can all but guarantee it will change one day and your expectation and specifications may not be verified.