Implementing persistence and setting up integration tests along the way

So far, we’ve used fake repositories in our tests, now it’s time to have an actual implementation of how we want to persist our data.

The goal is to be able to add entries when our application is running, and even if the application restarts, it should still have this data.

In order to be able to test this, we now need to setup our web api which is pretty easily done with Microsoft’s new minimal api. All we need to do is setup a new web project and map a post endpoint like so.

We would also need to register the dependencies we have so far. Given we have yet to implement our actual repository, we can simple use the same fake repository we used in our test for any instances of IRepository being requested.

We can run our web application and test it either via swagger but I prefer using http files because then, you’re able to keep the parameters that you’re passing when doing manual testing. Sending a few requests across will always return “interest registered successfully” because I have set the services to scoped and so we get a new instance of the FakeRepository (with an empty list) every time instead of expecting “Already Registered” to be return. Now we have a failing test!

The code so far can be seen here

Because I want to minimize doing tests manually, as soon as I have an endpoint that I need to test against, I usually start setting up an integration test. If anything, just to save me the clicks of running the app and triggering swagger or triggering the .http file. See Microsoft’s guide on setting up integration tests here

It’s super easy to setup, you basically need to set up a new project with a reference to Microsoft.AspNetCore.Mvc.Testing, add a reference to your web api project, and set up a test that looks like this an you’re done.

There’s other things that you could do like adding doubles of some services that are not core to your application, if you want to do partial integration tests as well so it’s a really useful framework to get familiar with.

TDD states we should write a failing tests, make it pass, refactor. So lets add another tests that calls register twice, and by our current logic, if the email address is already registered, we need to return a bad request.

At this point, I just want to be able to persist my data so that my app can retrieve records even if it is shut down. The easiest way to support this is using EF Core and a database like SQL so I’ll opt for that for now.

Since we’re starting to get into specific implementations, I now create an Infrastructure project that would house all the specific implementations of my application interface. I do this to make it easier for me to spot when I’m letting infrastructure concerns leak into the application, which I don’t want to happen.

The infrastructure will contain a SqlRepository implementation of the interface, as well as the EFCore related classes. Here we have a fairly generic implementation. I also defined an AggregateRoot interface to ensure that the entities we are persisting with this generic sql repository will always have a Guid ID.

After running the migrations against a local SQL Server, i finally have all unit and integration tests green. Next up will be refactoring.

The easiest updates was to refactor out dependency injections into their own extension methods. Again, I like separating Infra and Core services accordingly.

The code at this point can be found here

One more improvement that could help cleanup Program.cs was to make use of FastEndpoints. I was introduced to it in my recent projects and find it really easy and straightforward to use. It event provides a way to return error messages in the standard problem details format.

Full code is here

We have accomplished persistence, but its not yet the persistence of the events rather than the state that we had originally aimed to do in this series.

In the next post, we will look into how we can start persisting events instead of state.