How should I write automated tests for an SDK without making live calls to the API

apisdktest-automation

I've developed an SDK (link) for a RESTful API in PHP, and my automated tests (example) are actually live calls against the API, which is bad for multiple reasons, mainly:

  • it takes a long time (about 3 hours) for the tests to complete
  • it's impossible to do concurrent tests because they'll interfere with each other

I want to stop making live API calls.

I have an idea:

  • short circuit the request before it's fired
  • assert that the request URL is correct, in a way that, for example, if I pass a value John to the first_name param, I'd expect the request URI to contain first_name=John. Also, I have to be wary about optional params.

However, I don't think this is a full replacement because I lose the robustness of the response.

How do I know that the request is, in fact, valid without making a live call and checking the response code or JSON response?

Right now the library is using a random HTTP lib, but in the next major release which I'm working on right now, I will switch to Guzzle, which does support testing and short circuiting the request.

Finally, you can see an example of the API response here: https://reference.assemblypayments.com/#create-item

Best Answer

Identify what you're really wanting to test. Business rules are always paramount for me. I don't let business rule logic even know about the world around it. That means your business rules should only know about your robust response in the form of the most convenient data structure.

So long as that's all they expect you can test them with the most expedient way to create an example of that convenient data structure.

That may require code that converts the data structure to the convenient form. That you test with examples of both forms.

All that should be left to test is the access of the API. Here you can neglect the testing so long as access is simple. However, you can mock this with a local server that replicates the API if doing so actually does speed up the test.

If it doesn't at least you've separated what needs to be tested so you can work free of repeatedly running slow tests.

Related Topic