Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

How can I unit test my generic repository?

Unit testing code:

[TestClass]
public class UnitTestLanguage
{
    private IUnityContainer _unityContainer;
    private IUnitOfWork _uow;
    private IGenericRepository<Language> _languageRepository;

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

    [TestCleanup]
    public void TestCleanup()
    {
        _uow = null;
        _unityContainer = null;
        _languageRepository = null;
    }


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

        var insertedLanguage = _languageRepository.Find(newLanguage.Id);
        _languageRepository.Delete(newLanguage);
        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?

share|improve this question
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. –  Luc Franken Sep 24 '13 at 7:18

1 Answer 1

up vote 3 down vote accepted

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).

share|improve this answer
    
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? –  AliRıza Adıyahşi Sep 24 '13 at 11:00
    
In fact, I dont know how can I test respositories and services, without using, unity. –  AliRıza Adıyahşi Sep 24 '13 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 Sep 24 '13 at 11:35
    
you rigth, But there are not enough resource for dependency injection and repository unit testing. –  AliRıza Adıyahşi Sep 24 '13 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 Sep 24 '13 at 13:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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