WireMock.Net VS dotnet-testcontainers

I'd say that without wanting to refactor the code a little bit (maybe moving those HttpClients into a service so that they are easily mocked) your best bet would be to use something like WireMock or MockHttp.

WireMock

WiremockNet https://github.com/WireMock-Net/WireMock.Net

In this post, I'll explain how to create mocks for HTTP APIs in narrow integration tests using the WireMock.Net library.

Recently was pointed to WireMock for testing purposes.

I use WireMock (@ Java) to start a local webserver alongside the tests, this webserver will provide ‘real’ responses to the client. Here’s the C# equivalent: https://github.com/WireMock-Net/WireMock.Net

You could try out WireMock.Net: https://github.com/WireMock-Net/WireMock.Net/wiki/Using-WireMock-in-UnitTests

Use WireMock to mock responses from the endpoint that FooClient interacts with. This lets you exercise all of the code contained in FooClient in a realistic way, without using mocks, but still get the different responses you expect.

So what I usually do is: • Unit test underlying (public) services and application ‘core’ • Integration test (or w/e you call it) an entire functionality flow, by sending in ‘real’ requests on one end, and locally mocking/stubbing the application ‘edges’ that supply the response data. WireMock for requests to external services, H2 or Testcontainers for database.

I'd use testcontainers to spin up an instance of Progress and run against the actual thing. That way you get the benefit of testing against the actual database, but also that you don't have to set up a bunch of stuff locally.

Not every db support array as primitive, if you want to write integration tests and you have access to docker I suggest you testcontainers.

There is a rope which can help with this task: https://github.com/HofmeisterAn/dotnet-testcontainers

Dotnet.Testcontainers also comes with some built-in classes that wraps various services, one of these classes actually wraps a SQL Server Docker container and there are few more that covers the most common databases e.g.

You should also check out Docker, especially TestContainers. That way you can spin up databases (and other dependencies) on the fly and do operations on them. This means that you don't need to "fake" a database, as you will have access to a new one.