Edition 0 Updated to asp. Net core 0

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.