How to write test cases for APIs?

Questions
#1

For simple and small APIs, I might write the test cases in plain text or simple English. For complex APIs, I might use a spreadsheet to write test cases, or I might use plain text. Both these approaches can be cumbersome to write and a visual overload. I would like to express my API test cases or scenarios in ways (plural) that are easy to write and understand, and also visually appealing (like a mind map) if possible.

How do I make my APIs tests easier to write and read?

Have you used mind maps for API testing? Do you know any public examples which use mind maps to test APIs?

PS - Here is a post which is somewhat related to my post, but it does not answer my questions. The other post is about what to test in an api. My post is about how to express your api tests.

1 Like
#2

In my exprience, API Testing can be split into differnet parts:

  1. Does the API conform to standards (return codes)
  2. For given input, does the API return as I expect (response body)
  3. When I call the API, does the system state change as I expect (System testing)

Testing 1 and 2 is relitively easy in terms of writing test cases.

You basically need:

  • The endpoints /do/thing
  • The methods (GET/POST/PUT/DELETE etc)
  • Test input (Headers + body)
  • Expected output (Headers, response code, Body)

I usually use Jest for these tests, and for headers and response body I usually have a stored object in JSON or XML to compare against.

As for 3, system testing. Well, that is going to be down to exactly what the API and connected service does. And really any existing system testing techniques work here.

I hope this helps!

1 Like
#3

Why not simply use your favorite programming language to write those checks?
Un-executable descriptions will inevitably mean that subjective interpretation of the text will happen, creating thus confusion of the expected behavior.

2 Likes
#4

@joaofarias - It is a part of the process and I cannot change it. Others review the test cases or scenarios before testing and automation begins. A high level, 1-5 line overview of each scenarios is helpful. Its easy to keep each scenario within limits for UI, but its hard for non-trivial APIs. So, I am looking for ways to express scenarios in a neater way.

1 Like
#5

How complex are the scenarios?

Can they be broken down into smaller parts?

The APIs and related services I test tend to each have a relatively constrained purpose.

Is there any documentation or the services purpose you can use to add context?

Have you considered using decision tables or building flow diagrams?

I find models really help for understanding how to test connected services.