Testing HTTP clients and adapters

You don’t want your tests to make requests on a production server and a separate test instance is costly, so you have two realistic options:

1. Mock your requests. For example, by monkey patching some methods.
2. Set up a local fake HTTP server¹ and configure your code to use it.

Both approaches require similar efforts in terms of preparing fake responses, but the mocking approach has two major problems:

• You need to be careful not to mock sloppily, causing unwanted external requests, or mock too aggressively and not actually test much anymore.
• Your tests are based on implementation details, so if any internals change (you’re using a different HTTP client lib or rename some methods/classes), your tests will break even if the public interface didn’t change.

With a fake server, you don’t need to touch your client or adapter code at all. You don’t even need to know how the code works to test it, enabling black-box testing. If you forget an endpoint, the fake server will raise an error. Another nice benefit is that the fake-server tests will force you to properly separate code from configuration: you need to be able to pass in a different set of URLs, otherwise this approach won’t work.