I have read this article: https://www.gaui.is/how-to-mock-the-datacontext-linq/

Since this article is almost 4 years old I have no hope that in article's comments my question will be answered so I decided to ask it here.

In this article author creates another MockRepository and MockUnitOfWork classes and implements their own methods to match Repository and UnitOfWork methods. but uses List instead of DataContext.

If I use this approach, and in future I will change my implementation for Repository or UnitOfWork. It means that I have to change Implementation for MockRepository and MockUnitOfWork too.

It seems a bit frustarting for me. It looks like I am testing MockRepository and MockUnitOfWork separately and Repository and UnitOfWork still stays untested.

How do you think?

  • 1
    You mixed up some things. You want to test code X. Code X depends on item Y. Now you mock item Y in your tests. – Bernhard Hiller Jun 12 '17 at 7:37

If you follow the pattern described in the article, then you would only need to change MockRepository or MockUnitOfWork if the respective interface (IRepository and IUnitOfWork) changes.

The idea behind this is that you can unit-test all the other parts of your application without needing access to a real database (and without the trouble that data persistence in a proper database gives you while testing).

Only the Repository and UnitOfWork classes themselves (the ones that contain the actual database connection) would need a real database to be unit-tested and if their implementation is simple enough, you can even choose to defer testing of those classes till the integration or end-to-end tests.

  • Nice answer. I got the point now. Thank you for your time – Dato Maisuradze Jun 12 '17 at 7:20

The author is using a LINQ to SQL DataContext which is not that simple to mock. There are ways to mock it but you can simply go around that and create a fake implementation of a Repository and UnitOfWork to use in your tests. If you go the extra mile and create a viable mock for a DataContext then you shouldn't create mocks for your Repository and UnitOfWork.

  • Yes, as it seems if I want to unit-test Repository or UnitOfWork I have to mock DataContext, right? – Dato Maisuradze Jun 12 '17 at 7:22
  • In that case, yes. I assume the author didn't unit test his implementations otherwise we would have seen a mock for the DataContext. If your repository is only forwarding calls to the context you probably don't have to unit test it. – devnull Jun 12 '17 at 7:24
  • Let's say I have simple method in my repository like this: public T FirstOrDefault(Expression<Func<T,bool>> pred) { return pred!=null?context.FirstorDefault(pred):context.FirstOrDefault(); } should I unit-test this? – Dato Maisuradze Jun 12 '17 at 7:27
  • 1
    I don't see a reason to do so. – devnull Jun 12 '17 at 7:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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