1

Recently had a doubt about how and where to test repository methods.
Let the following situation: I have an interface IRepository like this:

public interface IRepository<T>
    where T: class, IEntity
{
    IQueryable<T> Query(Expression<Func<T, bool>> expression);
    // ... Omitted
}

And a generic implementation of IRepository

public class Repository<T> : IRepository<T>
    where T : class, IEntity
{
    public IQueryable<T> Query(Expression<Func<T, bool>> expression)
    {
        return All().Where(expression).AsQueryable();
    }
}

This is an implementation base that can be used by any repository. It contains the basic implementation of my ORM.

Some repositories have specific filters, in which case we will IEmployeeRepository with a specific filter:

public interface IEmployeeRepository : IRepository<Employee>
{
    IQueryable<Employee> GetInactiveEmployees();
}

And the implementation of IEmployeeRepository:

public class EmployeeRepository : Repository<Employee>, IEmployeeRepository // TODO: I have a dependency with ORM  at this point in Repository<Employee>. How to solve? How to test the GetInactiveEmployees method
{
    public IQueryable<Employee> GetInactiveEmployees()
    {
        return Query(p => p.Status != StatusEmployeeEnum.Active || p.StartDate < DateTime.Now);
    }
}

Questions

  1. Is right to inherit Repository<Employee>?
    The goal is to reuse code once all implementing IRepository already been made. If EmployeeRepository inherit only IEmployeeRepository, I have to literally copy and paste the code of Repository<T>.

  2. In our example, in EmployeeRepository : Repository<Employee> our Repository lies in our ORM layer. We have a dependency here with our ORM impossible to perform some unit test.

  3. How to create a unit test to ensure that the filter GetInactiveEmployees return all Employees in which the Status != Active and StartDate < DateTime.Now. I can not create a Fake/Mock of IEmployeeRepository because I would be testing? Need to test the actual implementation of GetInactiveEmployees.

The complete code can be found on Github

1 Answer 1

1
  1. This strikes me as a has-a relationship, since as you mention this class is acting as a filter. So rather than inheriting it should have a private IRepository<Employee> field that it can receive when EmployeeRepository is constructed.

  2. Having the option to provide an IRepository<Employee> would allow you to mock/fake it and separate the testing concerns.

  3. Yes, you don't need to create a mock object of the thing you're testing. You just need to be able to isolate the method's behaviour by providing ideal objects for the object you are testing to manipulate.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.