Why API Testing Is Complex – Input Data

I’ve given an example of how API testing can get complex. Let’s talk about more options to make things not so simple: Input data . The number of cases we can think of to test, with just the data of a single API, can fill hours of joy. Here’s an example. This is our API for today:

This is a scheduling API, using a POST with a body. The JSON body has those four fields, as in the example.

What kind of cases do we want to test?

There’s the “valid data” scenario, of course. Then, there are the logically “invalid” ones. For example, if a meeting with the same data (or partially) already exists in the database. Or, if the length field contains a negative number (I wish lengths of meetings could be negative.) . Maybe, we need to test it in collaboration with other APIs. As in, the data of the meeting I created with this API, can be retrieved with another. All these functional cases are great and need testing.

But let’s dive deeper, focusing on the body’s structure. We’re using JSON as payload, and JSON is text. We can do a whole lot of damage with text. We can check how the system behaves well when we send it, or if it is now a broken mess.

Here’s an example – missing fields:

Are all these fields required? What happens if we don’t send them?
What about we use the same fields, but send different types of data? Strings instead of numbers, or the other way around?

Maybe, the same fields appearing twice? Will at break the system? Will it take the first or the second value? Maybe neither?

And don’t tell me I can’t do it. I would, and have. The results were ug-ly.
What happens, if we send a completely different JSON, than what the tested system expects?

Let’s play with the content of the values. Instead of English, what about using non-so-English characters:

The topic is topic, by the way. Literally.

Finally, wouldn’t you like to see what happens, when we send this?

And why stop there? Why not send the body as XML, and see if it floats or sinks?

The underlying technology of web APIs is HTTP-based, meaning it is string-based. And there’s so much we can play with, and should check, when using strings. Testing APIs is fun, isn’t it?

Of course it is. Now, to join the fun, check out my “Automation API Testing” for developers, and “API Testing with Postman” workshop.