DbIntegrationTestHelpers 1.0.8

Description

There is a newer version of this package available.
See the version list below for details.
Install-Package DbIntegrationTestHelpers -Version 1.0.8
dotnet add package DbIntegrationTestHelpers --version 1.0.8
<PackageReference Include="DbIntegrationTestHelpers" Version="1.0.8" />
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add DbIntegrationTestHelpers --version 1.0.8
The NuGet Team does not provide support for this client. Please contact its maintainers for support.
#r "nuget: DbIntegrationTestHelpers, 1.0.8"
#r directive can be used in F# Interactive, C# scripting and .NET Interactive. 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.8

// Install DbIntegrationTestHelpers as a Cake Tool
#tool nuget:?package=DbIntegrationTestHelpers&version=1.0.8
The NuGet Team does not provide support for this client. Please contact its maintainers for support.

Introduction BuildStatus

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?

Unit tests in all glory

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.

Introduction BuildStatus

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?

Unit tests in all glory

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.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version History

Version Downloads Last updated
1.0.32 543 9/24/2018
1.0.31 459 9/15/2018
1.0.30 458 9/15/2018
1.0.29 466 9/15/2018
1.0.28 577 6/14/2018
1.0.27 572 6/13/2018
1.0.26 540 6/13/2018
1.0.21 590 6/13/2018
1.0.20 548 6/13/2018
1.0.19 594 6/13/2018
1.0.18 564 6/13/2018
1.0.17 569 6/13/2018
1.0.16 555 6/13/2018
1.0.13 548 6/12/2018
1.0.12 549 6/12/2018
1.0.11 559 6/12/2018
1.0.10 543 6/12/2018
1.0.9 552 6/12/2018
1.0.8 505 6/12/2018
1.0.7 550 6/12/2018
1.0.6 532 6/12/2018
1.0.5 566 6/11/2018
1.0.4 527 6/11/2018
1.0.3 504 6/11/2018
1.0.2 567 6/11/2018
Show less