DbIntegrationTestHelpers 1.0.31

There is a newer version of this package available.
See the version list below for details.
dotnet add package DbIntegrationTestHelpers --version 1.0.31
NuGet\Install-Package DbIntegrationTestHelpers -Version 1.0.31
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="DbIntegrationTestHelpers" Version="1.0.31" />
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add DbIntegrationTestHelpers --version 1.0.31
#r "nuget: DbIntegrationTestHelpers, 1.0.31"
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install DbIntegrationTestHelpers as a Cake Addin
#addin nuget:?package=DbIntegrationTestHelpers&version=1.0.31

// Install DbIntegrationTestHelpers as a Cake Tool
#tool nuget:?package=DbIntegrationTestHelpers&version=1.0.31

Introduction BuildStatus

A tiny helper assembly 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?

Unit tests in all glory


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

Just run Install-Package DbIntegrationTestHelpers



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 => () =>
            //or even seed directly
            this.Context.Products.Add(new Product(){Name="TheProduct"});

Context shared in test class

Add IntegrationTestsContextSharedPerClasss<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 shared for all unit tests within this test class. This is an approach which balances the indenpendence of tests with quick execution.

New context for each test

Add IntegrationTestsContextNotShared<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 an overhead for each test, during which a database is created and seeded. It might be large, depending on machine and database.

Context shared for all tests in all test classes

Add IntegrationTestsContextSharedGlobally<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.

Product Compatible and additional computed target framework versions.
.NET Framework net461 is compatible.  net462 was computed.  net463 was computed.  net47 was computed.  net471 was computed.  net472 was computed.  net48 was computed.  net481 was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
1.0.32 1,022 9/24/2018
1.0.31 829 9/15/2018
1.0.30 802 9/15/2018
1.0.29 841 9/15/2018
1.0.28 997 6/14/2018
1.0.27 963 6/13/2018
1.0.26 935 6/13/2018
1.0.21 1,025 6/13/2018
1.0.20 958 6/13/2018
1.0.19 1,032 6/13/2018
1.0.18 944 6/13/2018
1.0.17 976 6/13/2018
1.0.16 956 6/13/2018
1.0.13 920 6/12/2018
1.0.12 911 6/12/2018
1.0.11 946 6/12/2018
1.0.10 930 6/12/2018
1.0.9 936 6/12/2018
1.0.8 868 6/12/2018
1.0.7 911 6/12/2018
1.0.6 883 6/12/2018
1.0.5 1,022 6/11/2018
1.0.4 944 6/11/2018
1.0.3 873 6/11/2018
1.0.2 956 6/11/2018