Ok, I actually think testing is a very important part of development. I still haven’t come back from vacation feelings (and wake up times), so I thought I would learn about setting up automated testing for my API.
I have been putting off proper persistence implementation because I don’t want to start paying for SQL or any database till I have most of the MVP up and running. Maximizing the amount of work not done, one of the principles of the agile manifesto, was a phrase I thought talked about procrastination as a good thing but when I understood what it really meant, it actually makes sense. You can read a writeup of what it means here.
At this point in the project, I have the sort of MVP but I want to add a little more nice to haves but I can’t seem to focus when writing up the user stories, tending to overcomplicate and spiral out of control. Got a little bit too much creative energy from the break but I know that if I start writing them down, the MVP will cease to be minimum and it will never be finished. So I’m declaring this week as a honeymoon week but I want to put it to good use anyway, so what better way than setting up integration tests. That way, even if I start making drastic changes, I’ll have the tests to help me with regression testing and speed up development.
There are a lot of resources online on how to setup integration tests. Here is Microsoft’s https://learn.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-7.0
But basically, the steps I took for this project were:
Create an XUnit test project and add a reference to the API project as well as Microsoft.AspNetCore.Mvc.Testing
Make Program class public by using a partial class if your project uses top level statements.
If we wanted to use the API with all the dependencies as is, we can have the test class implement IClassFixture<WebApplicationFactory<Program>> and make sure Program is your API program class. I made the mistake of not adding the reference to my API at first and it ended up referencing some other Program.cs in a test class.
We should then be able to create a simple test method that calls one of our endpoints and assert responses.
In my case, I wanted to change the injected class when it comes to tests so I created a subclass of WebApplicationFactory and created an override for ConfigureWebHost. Here we can invoke ConfigureTestServices where we can then create the InMemoryRepository where I pass the seeded flag as true.
I encountered a little trouble here because initially, I only added IWishlistRepository and it was still running the un-seeded implementation. I thought it was enough to override IWishlistRepository but when I revisited my commands, I found I was injecting IAsyncRepository so I had to override that implementation as well. I probably could have fixed it by updating the constructors to inject IWishlistRepository instead. Maybe something to revisit later.
Now I have it setup to run tests, the next step will be to figure out what tests to actually write. Maybe something for today, or Monday. #TGIF
being in tech 