How can I unit test my generic repository?

Unit testing code:

public class UnitTestLanguage
    private IUnityContainer _unityContainer;
    private IUnitOfWork _uow;
    private IGenericRepository<Language> _languageRepository;

    public void TestInitialize()
        _unityContainer = new UnityContainer();
        _uow = _unityContainer.Resolve<UnitOfWork>();
        _languageRepository = _uow.GetRepository<Language>();

    public void TestCleanup()
        _uow = null;
        _unityContainer = null;
        _languageRepository = null;

    public void TestMethodInsertLanguage()
        var newLanguage = new Language { Name = "test_language" };
        var insertedRowCount = _uow.SaveChanges();

        var insertedLanguage = _languageRepository.Find(newLanguage.Id);
        var deletedRowCount = _uow.SaveChanges();

        Assert.AreEqual(insertedLanguage.Name, newLanguage.Name);
        Assert.AreEqual(1, insertedRowCount);
        Assert.AreEqual(1, deletedRowCount);

I use something like above. But I dont know this is the correct way to test repository. I cant find useful tutorial/article. How should be unit testing with generic repository CRUD operations?

  • 2
    Doesn't seem wrong. What I do see is that you test multiple cases in one test. That is something I would not suggest. You method is called: InsertLanguage but you test also delete. So you get a red flag: Test failed: InsertLanguage. You start looking at insertions but it can easily be the delete or lookup that fails. Sep 24, 2013 at 7:18

1 Answer 1


Apart from Luc's suggestion to test one functionality per test (method), I would suggest not to use unity for setting up the unit under test. Strictly speaking, this is no unit test anymore, because it tests both your repository and the configuration of unity.

This might not be a problem for now, but it can easily become one in the future. Consider, for example, the situation that someone extends you language repository by some online-lookup functionality. The respective request interface would probably be retrieved though DI. In consequence, your tests may suddenly start to fail at random, because of occasional connection timeouts.

From my experience I prefer to be strict about dependencies in unit tests, i.e., every input is replaced manually by a respective mock. This is the only way you can make sure that a test failure actually relates to some problem with the unit (or the expectations your tests express).

  • Thanks for suggestion. I m new for unit testing so I do not understand exactly, but you give me some idea, especially : "because it tests both your repository and the configuration of unity". Is there tutorial that you suggest about this topic? Sep 24, 2013 at 11:00
  • In fact, I dont know how can I test respositories and services, without using, unity. Sep 24, 2013 at 11:03
  • There are tons of materials about unit testing out there. One possible entry point could be this post on Stackoverflow. As a general rule of thumb: Consider your unit tests to be the specification of the tested unit. If there's something happening "under the hood" that influences the test results, you have a problem, because your specification is incomplete. DI (unity in this case) does nothing else than setting fields and calling methods. You can always do the same with manual calls.
    – Sven Amann
    Sep 24, 2013 at 11:35
  • you rigth, But there are not enough resource for dependency injection and repository unit testing. Sep 24, 2013 at 12:39
  • First hit on google for "unit testing dependency injection" explains why systems that make use of inversion of control (the principal dependency injection is based on) are easier to test. I suppose there's nothing special about unit testing a repository.
    – Sven Amann
    Sep 24, 2013 at 13:42

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.