DbIntegrationTestHelpers 1.0.8

Introduction

A tiny helper class that contains some boilerplate code for creating DB integration tests in EntityFramework.
Remember - unit tests do not allow you to test everything that you should test. Integration tests are good, especially if writing them is simple. Don't take my word for it, have a read, e.g. here: https://blog.kentcdodds.com/write-tests-not-too-many-mostly-integration-5e8c7fff591c or here https://gist.github.com/alistairmgreen/ca3f7baddb737fd91e6bf7399ba6deeb

Why unit tests are not enough?

Installation

Available as a Nuget package - https://www.nuget.org/packages/DbIntegrationTestHelpers/

Just run Install-Package DbIntegrationTestHelpers

Usage

General

Regardless of which approach (instance or static) you choose as the base class for your test class, you gain access to a this.Context property, which will contain your DbContext.

Your DbContext is required to have a constructor which allows passing connection string.

 public MyDbContext(string nameOrConnectionString) : base(nameOrConnectionString){}

The base class allows also specifying a SeedAction, as follows:

protected override Action SeedAction => () =>
        {
            SomeStaticClass.DoSomeSeeding(this.Context);
            this.DoSomeMoreSeeding();
            //or even seed directly
            this.Context.Products.Add(new Product(){Name="TheProduct"});
            this.Context.SaveChanges();
        };

Instance approach

Add IntegrationTestHelpersBase<T> as base class for your test class. The type parameter should be your DbContext type.

You now have access to this.Context which is instance of your DbContext - the database behind it will be dropped and recreated with each test method run - this means there is a little overhead for each test, during which a database is created and seeded. In my tests, the overhead is approximately 2 seconds for each test.

Static approach (faster, but tests are interdependent)

Add StaticContextIntegrationsTestsBase<T> as base class for your test class. The type parameter should be your DbContext type.

You now have access to this.Context which is a static object of your DbContext. Due to that, bear in mind that the tests methods you write will have to be structured in a certain way (you cannot have each test reference a mock entity with ID 1).

The tests will use a new, test only database (LocalDb). The database is wiped only when a new test run is exectuted, so you can have a look at what entries were added etc., anytime after the tests (regardless if succeeded or failed).

Why not in-memory?

There are some in-memory DbContext providers, such as EFFORT. Why not use them? While I believe these are great and powerful tools (sure more mature than this project, so far), I ran into problems where an in-memory provider gave me false positives. At some point, I have introduced a new entity in my code-first app, and messed a FK relationship. Unit tests with Effort did not detect this change and kept on passing - and that is not what I wanted. I wanted to be sure that my entity relationship is not messed up by a simple bug - hence, this project.