4

Is there any way to mock dbcontext in situation like this? Im using cqrs. 

  public class QueryHandler1 : IQueryHandler<Query1,string>
  {
    private readonly IDbInvoker invoker;

    public QueryHandler1 (IDbInvoker invoker)
    {
        this.invoker = invoker;
    }

    public string Handle(Query1 query)
    {
        //Here I want to have my mocked context somehow.
        return invoker.Invoke<MyMockedContext, string>(context =>
        {

            //logic which I want to test with my mocked context
        });
    }
TjDillashaw
  • 787
  • 1
  • 12
  • 29
  • Unit Testing and Entity Framework are mutually exclusive. – Aron Feb 21 '17 at 09:21
  • Maybe, but In different scenario mocking DbContext it's not a big problem. – TjDillashaw Feb 21 '17 at 09:24
  • Mocking the DbContext is not testing the DbContext. In this case mocking does nothing at all, it also removes EntityFramework from the equation. Perhaps you are talking about Faking. But again that would Fake out the Entity Framework. – Aron Feb 21 '17 at 10:13
  • Are you after the steps to mocking calls that take callbacks (see [Arg.Do](http://nsubstitute.github.io/help/actions-with-arguments/) or [When..Do](http://nsubstitute.github.io/help/callbacks/))? Or how to get an instance of `MyContext` in `Invoke`, or how to change this type for testing? – David Tchepak Feb 21 '17 at 23:14
  • I need to pass my fake context into this generic `Invoke` method somehow. And then test the logic which is inside `Handle` method. Which will be operating on fake context. Simplyfying I dont want to call database for test this `Handle` method logic. – TjDillashaw Feb 22 '17 at 08:18
  • @Aron you are very wrong there, saying they are exclusive. – zaitsman Feb 27 '17 at 11:32
  • You kind of have two options: 1. Use Microsoft Fakes. This way you shim everything of the MyMockedContext and get a harness for your code. Sadly, you need VS Enterprise for that. 2. Use localdb and create an actual db for your actual test, then teardown after the test. Will make it take 2-3 seconds to run each db creation, but will be run against a real-ish db. (a subversion of this is an in-memory db, e.g. using `Effort` framework). This option is free, but painful – zaitsman Feb 27 '17 at 11:34
  • @zaitsman Nope. EF is a wrapper for DbCommand, which connects to a SQL database. A unit test is a test of the smallest testable part of the software. It's by definition not a unit test if it involves a friggin SQL database. – Aron Feb 27 '17 at 11:35
  • @Aron Okay, so you want to play semantics. call it 'integration test' if you prefer. – zaitsman Feb 27 '17 at 11:43
  • Thanks for comments. I solved that by little workaround. I have created a factory which returns Db Contexts and then I mocked this factory by NSubsitute `.Returns(new MyMockedContext)`. – TjDillashaw Feb 27 '17 at 16:00
  • @TjDillashaw I recommend you answer your own question and mark it as the answer for anyone visiting this question in the future. – AzzamAziz Apr 14 '19 at 04:27
  • https://learn.microsoft.com/en-us/ef/core/providers/in-memory/?tabs=dotnet-core-cli is a good option to create fake objects in EF Core context. – Jairo Alfaro May 10 '20 at 02:05

0 Answers0