-1

I am new to use NUnit integration testing with Asp core 2.2, I have already core RESTful Api but have no idea how to configure NUnit to implement integration test. Usually I Implement it using Configuration file from Migration Folder as the following but no more exists in ASP Core 2.2 and I don't know what the new alternative.

        var configuration = new Migrations.ApplicationDbContextModelSnapshot();
        var migrator = new Migrator(configuration);
        migrator.Update();

So please If you don't understand my question I just need an explicit link to use NUnit Integration Testing with .Net Core 2.2.

Amin Mohamed
  • 640
  • 7
  • 10
  • What do database migrations have to do with integration testing? You ask for an alternative but it's not clear from your question what you want an alternative to. Could you perhaps explain what specifically you are having trouble with? – Tom W Sep 26 '19 at 15:37
  • I was using migration in my application to create another Latest DB update to test it – Amin Mohamed Sep 26 '19 at 15:39

1 Answers1

1

An integration test should not be connecting to a real database. Integration testing is about ensuring components function together correctly, not any concrete backend implementation. As such, you should be using the in-memory database provider for EF Core. This will automatically "migrate" (really it's just setting up a representation of what your database looks like in memory each time it's instantiated), so it's not necessary to take any further action. Just keep in mind that EF-in-memory database is also a non-relational database, so if you want to keep the relational integrity of your entities like the foreign keys, you should use SqlLite in-memory database. Below is an example:

var connection = new SqliteConnection("Data Source=:memory:");
services.AddDbContext<WebApi1DbContext>(options => options.UseSqlite(connection));
Zinov
  • 3,817
  • 5
  • 36
  • 70
Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
  • Is there any way to use NUnit for integration test? "An integration test should not be connecting to a real database" So I have to use mocking? Please give me a good tutorial if you know – Amin Mohamed Sep 26 '19 at 18:07
  • 1
    NUnit is just the test framework. You can use whatever you want. It has no bearing in general on how a unit test is constructed. Unit tests in general need to use mocks because you cannot use actual dependencies. Doing so would make your test an integration test, not a unit test. I'm not familiar enough with NUnit, but if it doesn't have mock capability itself, you may need an additional library for that purpose, like Moq. – Chris Pratt Sep 26 '19 at 18:14
  • 1
    Sorry, I forgot the context of the question and misunderstood your comment. I'll leave my previous comment because it's good info to have. As far as integration testing goes, the same applies for NUnit. You can of course use any test framework here. What I'm talking about is that the integration tests should not be connecting to real stuff. It's about showing that the components all work together. You may use mocks. Real stuff can go down and can have sometimes significant latency. Tests need to be fast or their usefulness goes away. – Chris Pratt Sep 26 '19 at 18:19
  • 1
    It's not important, at least in this context, that your infrastructure is correct. You're looking to ensure that the functional units of your code, when combined, work correctly together. – Chris Pratt Sep 26 '19 at 18:21
  • Because I already just used mocking to avoid touching real DB suffered a lot of problem like the link below and someone suggested to not use mock and test the external source. So now I don't know what I have to use, Mocking not sufficient with EF and there are a lot of changes to use EF Core as previous version of EF – Amin Mohamed Sep 26 '19 at 18:34
  • "that's not something you should be doing. if you want to test your database layer then either use integration testing, as in use your real database or use an in-memory one. either way, you're working with an actual database. don't try to mock Entity Framework, you'll waste your time for nothing " https://stackoverflow.com/questions/57825454/how-to-test-related-objects-in-ef-repository-using-moq – Amin Mohamed Sep 26 '19 at 18:34
  • 1
    You *can* mock you EF context, but it would be a ton of work, and it's just easier and more foolproof to use the in-memory provider. That is why it's recommended. However, other things should be mocked, unless there's a similar "dummy" provider already available. For example, for logging, you can just use debug or console providers. – Chris Pratt Sep 26 '19 at 18:46
  • 1
    The point you should take away is that the integration test should really not connect out to anything. Any external dependency or infrastructure constraint represents a point of failure for your test and you only want the test to fail when there's an actual code problem, not just some connectivity issue. – Chris Pratt Sep 26 '19 at 18:49