Tag Archives: testing

Manually Adding DbContext for an Integration Test

In EF Core, there is an extension method that allows you to add a DBContext, called AddDBContext. This is a really useful method, however, in some cases, you may find that it doesn’t work for you. Specifically, if you’re trying to inject a DBContext to use for unit testing, it doesn’t allow you to access the DBContext that you register.

Take the following code:

services.AddDbContext<MyDbContext>(options =>

I’ve previously written about using UseInMemoryDatabase. However, this article covered unit tests only – that is, you are able to instantiate a version of the DBContext in the unit test, and use that.

As a reminder of the linked article, if you were to try to write a test that included that DBContext, you might want to use an in memory database; you might, therefore, build up a DBContextOptions like this:

var options = new DbContextOptionsBuilder<MyDbContext>()
var context = new MyDbContext(options);

But in a scenario where you’re writing an integration test, you may need to register this with the IoC. Unfortunately, in this case, AddDbContext can stand in your way. The alternative is that you can simply register the DbContext yourself:

var options = new DbContextOptionsBuilder<MyDbContext>()
var context = new MyDbContext(options);
services.AddScoped<MyDbContext>(_ => context);

AddMyData just adds some data into your database; for example:

private void AddTestUsers(MyDbContext context)
    MyData data = new MyData()
        value1 = "test",
        value2 = "1"                

This allows you to register your own, in memory, DbContext in your IoC.

Chaos Monkey – Part 1 – Simulating a dodgy network on a local IIS

I thought I’d share this little DOS script that I’ve been using to simulate an unstable network connection on a local IIS:

	ping -n 1 -w 10000 > nul
	GOTO startLoop

Not rocket science, but it does what it says on the tin. I saved it into a batch file and run that along with my app.