Mocking the DAL/Repository that I pass to the BLL/ViewModels for testing purposes is not much different than creating an in-memory DAL. Right now I'm using an in-memory DAL in a new project instead of mocking it and it's working very well so far (even easier than setting up the mocks I'd say).

Since I haven't seen this done in online/book examples I thought I'd ask. Is there a problem with writing an in-memory DAL for testing the BLL/ViewModels?

On my architecture all components share a common library with all the relevant interfaces. Things are late bound which allows me to swap any component for another of the same interface.


There isn't necessarily anything inherently wrong with choosing to use an in-memory DB instead of mocking things out, but there are some tradeoffs. The main one IMO is performance, which may or may not be a concern to you, depending on how many tests you have and how much data you need to setup.

At my company our main product has a few thousand tests, about half of which are integrated with our DB. The rest are all mocked. The DB tests take about 3-4 minutes to run, while the mocked tests take about 15 seconds. Of course, a real DB is a lot slower than an in-memory DB, but even so mocked data is faster, and if you had a goal of being able to do a compile+test loop in a minute then it could be difficult to hit that target using any database. Also, if your tests connect to a DB, it may be impossible to run them multithreaded. We use NCrunch during development to run our mocked suite in the background using all available cores, so we can get feedback while we're coding.

Mocked data most likely will require more code upfront, and may be too time consuming if you don't have good frameworks available for assisting in mock data generation. So you'll always have to consider the cost/benefits.


There's absolutely nothing wrong with testing against an in-memory DAL as long as you realize it's integration testing as opposed to unit testing.

As soon as your BLL tests start relying on in-memory persistence, you're really testing 2 things : the in-memory DAL and the BLL. Your tests are no longer isolated and they could break for a much larger number of reasons. There can still be value in this kind of tests as they allow you to verify your system plays well with a (relatively) representative persistent storage.

However, the only way to test your BLL in isolation, in other words to assess the basic, atomic correctness of your objects, remains mocking out any external dependency.

  • I've read around the net about people who use NHibernate using SQLite for "unit" testing, even on stackoverflow. +1 for pointing out that it's really integration testing. Feb 28 '12 at 14:57
  • Mocks or not you'll have to write a piece of code that will expose the relevant part of the DAL interface and can store/retrieve an object in memory. Why is it a "unit test" if you put that code in a library ending with .Test but an integration test if you put that code in a library that ends with .DAL?
    – Manuel
    Feb 28 '12 at 16:19
  • 1
    I was thinking about that, and I think it has to do with the complexity and purpose of the test code. If that piece of code is very simple, and the only purpose of that piece of code is to "pretend" to be the another piece of code for testing, and it's only sensible to use that piece of code for that testing purpose, then I'd say it is unit testing. If it becomes complicated enough that it a) would be useful as a DAL outside of the testing context, or b) would need its own suite of tests, it's integration testing using a complex BLL and a complex DAL. I admit that that is a very broad line. Feb 28 '12 at 20:14
  • Very broad indeed. Pretty much anything that can make an in-memory DAL an "integration test" could be said/done for the mocking setup.
    – Manuel
    Feb 29 '12 at 0:03
  • @Manuel Except that the mocking setup relies on third-party code (assuming you're using an isolation framework, which should be the case most of the time nowadays) and it's pretty commonly accepted that you can trust that code without testing it -"don't test the platform". This is not the case with the in-memory DAL solution. Trust me, having to inspect the correctness of only one code construct instead of 2 combined saves you huge amounts of time when a broken test shows up. Also see stackoverflow.com/questions/520064/… Feb 29 '12 at 13:13

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.