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.
Is there a problem with writing an in-memory DAL for testing the BLL/ViewModels?
design patterns;architecture
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.