Implementing integration and functional tests for each microservice As noted, integration tests and functional tests have different purposes and goals. However, the way
you implement both when testing ASP.NET Core controllers is similar, so in this section we
concentrate on integration tests.
Integration testing ensures that an application’s components function correctly when assembled.
ASP.NET Core supports integration testing using unit test frameworks and a built-in test web host that
can be used to handle requests without network overhead.
Unlike unit testing, integration tests frequently involve application infrastructure concerns, such as a
database, file system, network resources, or web requests and responses. Unit tests use fakes or mock
objects in place of these concerns. But the purpose of integration tests is to confirm that the system
works as expected with these systems, so for integration testing you do not use fakes or mock objects.
Instead, you include the infrastructure, like database access or service invocation from other services.
Because integration tests exercise larger segments of code than unit tests, and because integration
tests rely on infrastructure elements, they tend to be orders of magnitude slower than unit tests. Thus,
it is a good idea to limit how many integration tests you write and run.
ASP.NET Core includes a built-in test web host that can be used to handle HTTP requests without
network overhead, meaning that you can run those tests faster than when using a real web host. The
test web host (TestServer) is available in a NuGet component as Microsoft.AspNetCore.TestHost. It can
be added to integration test projects and used to host ASP.NET Core applications.
As you can see in the following code, when you create integration tests for ASP.NET Core controllers,
you instantiate the controllers through the test host. This functionality is comparable to an HTTP
request, but it runs faster.
