0

What's a good approach for writing unit tests for the following GetMyObjectsFiltered(...) method in a EF4 repository:

public static class MyRepository
{
    public static List<MyObject> GetMyObjectsFiltered(string searchFilter)
    {
        var myQueryableObjects = GetMyObjects(searchFilter);

        if (false == string.IsNullOrWhiteSpace(searchFilter))
        {
            myQueryableObjects = myQueryableObjects.Where(o => o.MyProperty.Contains(searchFilter));
        }

        return myQueryableObjects.ToList();
    }

    private static IQueryable<MyObject> GetMyObjects(string searchFilter)
    {
        using (MyDB_ModelContainer model = new MyDB_ModelContainer())
        {
            return model.MyTable.AsQueryable();
        }
    }

}

Can I inject the MyDB_ModelContainer and still utilise the using statement?

Mark Cooper
  • 6,738
  • 5
  • 54
  • 92

3 Answers3

2

well what an irony you are asking about unit testing and you have a static method right there..

rread this: Static methods are death to testability

Also related to your question.. unit testing repository code is really not needed if you dont have business logic there cos you will basically end up testing the ORM as part of your unit tests which is not necessary as the ORM writers would have already taken care of it.

If you refactor the static method to another interface implementation then you could mock an implementation of the interface and inject it into your class.. the mocked implementation will return you the data that you want to test based on various conditions.

I would suggest you look at mocking frameworks like moq.

Since it has business logic you could probably move that to a separate class that represents what it is doing. then your repo could still be the interface but you will moq the data that will be used by your new class..

Baz1nga
  • 15,485
  • 3
  • 35
  • 61
  • There is some business logic there - the `GetMyObjectsFiltered()` method is returning a subset of the data. I agree that the `GetMyObjects()` doesn't need testing... – Mark Cooper Sep 20 '11 at 10:02
  • I can refactor the static out if needed. – Mark Cooper Sep 20 '11 at 10:03
  • Unit testing repository is a) wrong b) not needed. You are most probably using repository to unit test your upper layer by mocking repository but not by mocking what is inside repository - that is a big difference. If your repository code touch EF and uses linq-to-entities it cannot be effectively unit tested - it must be tested by integration tests but your upper layer can be unit tested with mocked repository (unless it exposes `IQueryable` or consumes Expressions). [Here](http://stackoverflow.com/questions/6766478/unit-testing-dbcontext) is example why. – Ladislav Mrnka Sep 20 '11 at 10:29
  • OK, a mocking framework is what I expected to be offered. Am using JustMock and wanted to ensure this was a sensible approach, thanks :-) – Mark Cooper Sep 20 '11 at 12:51
1

There is no way to unit test repository code. Repository code wraps data access so the only reasonable test is integration against real database = no mocking or faking but executing the real code and evaluating that it returned correct results from a testing database.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
0

In the end I have refactored out the static class, and made a very thin layer over EF that returns only IQueryable types. Implemented via an interface this class can then be easily stubbed using Moles. A full description is provided in the following blog post:

Mark Cooper
  • 6,738
  • 5
  • 54
  • 92