Help architecting a testable API client

Question

I have to interface with an web API. It accepts post requests and returns XML data. It requires a lot of asynchronous processing on the client side, so that it can retry multiple times in case of failure without interrupting the main client process. The code needs to be well tested. I am creating a mock version of the API to test against locally, and writing unit tests which connect to it. Is this a good approach for testing? Should I also have versions of the client API that fake a connection to the server and do not actually connect? (just return mock data)

I am trying to also figure out the best architecture for the request / response classes. Should I just serialize the response into a class? Should have have some sort of mapping file that maps XML fields to class properties? I was thinking about having a request class for each request, which follows an interface. I could then have a ApiRequestSender class, and also a AsyncApiRequestSender class, which sends the request and gets the response. The only thing I am confused about there is how to get the correctly typed Response, since there are 4.

Thanks in advance. I'm hoping to get some answers, but generally when I ask architecture based questions I don't get any replies : <

Answer 1

I think mocking the API is the way to go. The purpose is to test the client side of your application, not whether the API can connect, this will have no added value for your tests.

Don't re-invent the wheel: use serialization instead of writing your own mapping mechanism.

Answer 2

Definitely a good way to go so far.

• Mocking will help you get a lot of cases done without actually having to hit the service.
• If possible, check if you can wrap the API input/output into your own class for your code so that you can code against your classes & not worry about the states of the response which will get wrapped
• Typically, I would make it into a IService or a IRepository implementation & abstract your code from the web API & use a DI container to inject your mock implementation for testing & the real API for the application
• As @Gerrie mentioned, don't re-invent the wheel, unless it is square :)

HTH