In Memory database vs Moqing framework in .NET Core [closed]

Question

we are going to implement TDD approach in our next project. So I have been studying Unit Testing with NUnit in ASP.NET Core. As I am new I am confused about few things. So I would like to share these questions with you for making decisions based on the expert opinions.

1. What are the Pros and Cons of Mocking database and In-Memory database?
2. In which situation, we should use Mocking and in what situation we should go with InMemory database provider?
3. Which is the better approach, using InMemory or using Mocking?
4. Can we implement both approaches together in the same project?
5. For integration testing, should we use mocking or In Memory?
6. Is it a better approach to use the In-Memory database in Unit Testing?
7. While testing Business Layer, should we use Mocking or In-Memory database?
8. While testing MVC Controller, should we use Mocking or In-Memory database?

Please help me to find the answers to these questions. It might be that, some questions are similar, however, I don't want to remove them for having a better understanding from you guys. Thanks.

Answer 1

There's a varying array of opinions to all of this, so I think you're going to have a hard time getting any definitive answers. That said, my personal take is that the in memory database is just fine to use for unit testing. Some hold the opinion that it's technically integration testing when you use the in-memory database in EF, because you're actually involving all the EF machinery. However, I have two points in opposition to that theory: 1) It's in-memory and therefore not actually a realistic integration test (since you'd obviously not be using an in-memory database in production) and 2) there's little difference between that and creating a complex mock that returns data from some in-memory collection.

As a result, I think it's just fine to use the in-memory database provider in EF for unit testing. It's simply saving you the time of having to scaffold a mock, which for something like mocking an ORM like EF can be quite significant. However, it has its own baggage, as well, so I'd only recommend doing that if you're testing a method that intrinsically relies on EF. For example, if it's a class that you inject the EF context into and you're testing a method that depends on that, then yes, use the in-memory provider and inject an actual context. However, if you're just testing a method that operates on some arbitrary set of data that you pass into it, then just use a text fixture for that, instead, rather than bootstrapping a EF context, just to pull some data out of to feed to the method.

As far as integration testing goes, it really depends on what you're testing. Even though an integration test by definition involves multiple different components, you should still ideally limit the scope of the test as much as possible. Therefore, if you're doing something like testing that an action result, you'd use the in-memory database for that, since you're concerned about the result, not that the connection to the database works correct. However, if you have an integration test that's actually looking at database-related integration, then you'd probably be better off simulating a real connection to ensure that things like your connection string are correct. For the most, though, yes, you should use the in-memory provider for integration testing for most things.