inproctester | WebDriver extensions to enable in-process testing | Functional Testing library

This can be accomplished by hosting your API in process, interacting with it - in process - whilst using test doubles at the edges of you API, or (put another way) using test doubles for external collaborators.

This allows an API (and its core behaviour) to be tested in a test (unit/integration depending on opinion) without ever hitting a network or database or filesystem.

This testing will provide coverage but obviously not all the coverage you need

In .NET core you can use TestServer included in the Microsoft.AspNetCore.TestHost package.

If your API is simple enough you can perhaps reduce your types of testing (N.B. I am not suggesting reducing coverage)
This approach is alluded to in the slide deck you mention on page 8/25

Paraphrasing. If the logic in the API is small, component tests may be favourable to isolated and sociable unit tests

This approach is also recommended in the Spotify "Honeycomb" style testing. They call component testing of an API Integration testing (which coincidentally Microsoft also call it when they are using TestServer in their tests (second link for concrete examples)

• https://labs.spotify.com/2018/01/11/testing-of-microservices/
• https://docs.microsoft.com/en-us/aspnet/core/testing/integration-testing

I think that the thrust of the approach (regardless of its specific name) is that in process testing is fast and external collaborators are replaed with test doubles.

One thing worth noting is that "out of process" component tests are basically end to end tests but with all external collaborators swapped out with test doubles.

These may be a bit slower than in process component tests but exercise a bit more of the "stack". I'd suggest that if you are going to end-end test anyway, I'd try and do in process component testing as much as possible.