Test Features, Not APIs

I want to talk about API testing today. But not really.

When we’re testing APIs, we usually think about “how they work”. But in fact, we’re not really interested in the APIs. We’re interested in the features that they make up.

The same API call, in different contexts, can have different results. Without this context, we can miss out on things we’d like to learn about the system.

So for our subject today, let’s talk about different scenarios of deleting a record. This is Delete API, that deletes a book by it’s ID. The ID is passed as a query parameter.

I think we can all agree that after deletion, we don’t expect the book to be there. Testing the feature of deletion, includes calling the DELETE API, but also includes calling this GET API for the book:

And, it may also include calling GET for all records, to see our book is not there.

To improve our confidence that the book was deleted properly, we can also try to create a new book with the details of the deleted one.

Is it WORKING?

Is that enough to say the Delete feature works?

We can call the API on an existing book, of course. But we can also try to delete a non-existing book. We can call it twice on an existing book. At first, we expect the book to be deleted, and after that to fail, because why would you delete a book that was already deleted?

What if the existing book, the one I’m trying to delete, was not created by me, but by another user? Can my delete operation succeed? What if I don’t have permissions to delete the book? Or I’m not even authorized in the system?

And let’s do some more digging. I mean deleting. What if the book record was created a year ago? Can the delete succeed? How about 10 years? Is the behavior going to be the same? Maybe we can’t delete old stuff.

Or maybe, the book was used in the system, and we can’t delete books that have been bought before…

But wait, there’s more!

What if our application does not really delete stuff? It just marks it as deleted, never to be shown again? Well, to most people. An admin can actually see this data if they needed.

And just to make it fun, maybe it’s marked to be deleted somewhere in the future. So currently it’s not available in one way, but after the future deletion it will not be available in a any other way.

One more, I know you want one more. Let’s say there’s a different way to delete the book, in the format of a path parameter, like this:

Does the behavior change because I did it in a different format? How do the different combinations I mentioned play out? It would be interesting to test!

API testing is not simple!

API testing can get really complex really fast. But, like I said in the beginning, it’s not about testing the APIs- it’s testing the features.

We can test different API calls, in different orders, with different contexts in different times, and even from different locations! We may get results and behaviors we expect, or get surprised. This is what testing is all about. Learning about how features work. But not in term of APIs – we test as the user expect to see the results using their scenarios. Along with the results they expect to see.

We should understand the system, and then look at the APIs as the accessors to the behaviors of the data it allows us to use. And then we need to get into the head of the user, and test – not a single API, or even multiple, but the test the APIs in the context of the user’s flow.

Want to learn about API Testing? Check out my upcoming online workshop on Postman Automation.