Note: This makes the assumption that your integration tests don't use external dependencies directly
One problem we face when writing mocks for integration tests is that it can take quite some time to mock every dependency; imagine if you have 1 feature that needs to call 3 external APIs and you want to write several tests that cover happy and unhappy paths! Luckily, WireMock provides the ability to serve as a proxy to the real API and store its requests and responses.
In the Server folder it contains a custom WebApplicationFactory that spins up a WireMock instance for FunTranslation upstream. There's also a ICollectionFixture that can be used by all tests to share the same WebApplicationFactory instance. The WAF configures the FunTranslations WireMock server to proxy calls that are not already mapped in local files, and store new requests/responses.
In Server/DelegatingHandlers we have one from the previous no leak project; and a new one that will add a x-scenario header to every http request, this way it will be easy to identify which test made which request and avoid clashes.
The tests are in Features folder and are written in Arrange/Act/Assert style. We are testing a whole feature, starting at the entry point (API in this case) and verifying the response is what we expect. There's no need to use the WireMock API (WireMock.Given) as each request and response gets stored in MockData/__admin.