Challenges while API testing

🗄️ Archive
1

What challenges are included under API testing?

2

The question seems vague and the answers can be endless based on context.

So here are a few of the challenges I’ve been facing recently, based on the context I work in (developing a web-app for businesses, the nature of the business might not be important)

We have collected information from an API, what are we going to do with it?
Are we collecting so much from an API that we’re hampering performance?
The API allows for inserting data errors under very specific circumstances (i.e. white space at start and end of string), are these errors handled somewhere else? so they need to be handled at the API level?
How do I talk about the results of my tests?
How do these tests relate to back-end test efforts or UI test efforts?

… There are more items. Hundreds more. Thousands more. I would say talking about the tests is probably the biggest challenge, but solving that challenge will lead to the greatest reward.

For more information about How To (and some of the challenges there), I’ve been taking Hilary Weaver-Robb’s Automating API Checks With RestSharp course here on the Dojo, and it is brilliant.

2 Likes
3

Some of my latest challenges in the context that I’ve worked in with APIs:

  • the API is shared, any change you do onto it for our product could impact 2-3 others;
  • the server on which the API is hosted is shared; any load added will be pooled with 20 other products; don’t consider you can use anything, in any way, at any time from the API - consider caching or rescope the integration;
  • the API you call can have another API it calls, which has another API it calls/or DB; not all layers are under your product scope, multiple other internal or external teams will handle those other layers, but those layers can have problems you might have to dig into or uncover;
  • used external APIs can have bugs - many bugs; even though the provider will say they have a high quality thing because they do X and Y practices/technologies; be skeptic about all integration points;
  • any documentation can be misleading; I learned to distrust documentation, use it as a guide, try the thing out and check for myself if that’s reasonably close to what I would need from the API;
  • two APIs which should integrate with each other could be built so wrongly that you’d require months to rebuild them; teams of product managers, developers could misunderstand each other in alignment meetings, not question and not talk to one another when developing; I learned to question each of the parties at the same time, and separately and help them align each other with revealing problems in their thought, naming, idea generation, assumption making process;
  • APIs use data to process: input data can be wrong, output data can be wrong, transformations can be wrong;
  • those that tell you how the API should work(an external API with which your API communicates) can be wrong; you might have to check it for yourself - reverse engineer the business requirement, check code, test product;
  • naming of fields across multiple APIs can be confusing; systems/APIs can have for the same fields, the same names but, in each of the system the meaning of the field is different;
  • if you’re staying for a longer time within a project/product development, consider learning external systems and APIs, their gaps, problems, works; be fluent in that other system’s language; helps in identifying problems
  • APIs can have different owners and different understanding of what is to be expected of this API; Assume that any API is incomplete, but focus on what can help your product move forward;;
    …and so on…not enough place to expand more challenges;
2 Likes