For certain types of code, unit testing works brilliantly, flows naturally, and significantly enhances the quality of the resulting code. But for other types of code, writing unit tests consumes a huge amount of effort, doesn’t meaningfully aid design or reduce defects at all, and makes the codebase harder to work with by being a barrier to refactoring or enhancement.

It’s pretty simple as there’ great support from Microsoft.AspNetCore.Mvc.Testing and Microsoft.AspNetCore.TestHost nuget packages. I’ve used XUnit together with packages mentioned. In my opinion it works best due to ClassFixtures and Collections that XUnit is providing.

This time instead of manual testing, we will make automated integration tests that make testing the API's behaviour easy. They can also confirm the API conforms to its contract. But the authentication requirement presents some challenges.

If you want to run an integration test for your ASP.NET Core app without also testing lots of external dependencies like databases and the like, then the lengthy official ‘Integration tests in ASP.NET Core‘ documentation shows how you can use stubs to replace code that talks to a database or some other external service. If you want to use mocks, this is where you run out of guidance and runway.

This blog post shows you how to create fake users for ASP.NET Core integration tests and write effective extension methods to keep integration tests shorter.