Once upon a time, I had an API, and I wanted to test if it works. All great fairy tales begin like that. Here it is.
But listen up. I actually knew it worked. I got a 200 back! Yes, the mother of all HTTP statuses. The status goddess was with me.
And I declared the API “working”.
Ok, not yet.
Since that was a GET API, let’s take a look at what I got.
Ah, not only OK, but got a response too. Let’s jump into my brain, and see how it analyzes what it sees
- transaction_id – Ignore, how can I tell if a GUID is correct? Or if it’s a GUID at all?
- transaction_date – Hmm, not recent. Maybe important, but I can’t really corroborate it’s the right date.
- item_id – Yeah, that’s what I sent as a parameter.
- item_name – Yeah, what I wanted to buy
- total_paid – Sounds about right for a slightly destroyed starship.
Ok so basically, I declared it “working” by the item_id and the item_name fields. But is that the right way to do it?
To be more correct, we need to control and know what we expect to see. Sometimes we can’t control everything in integration tests (like the price before inflation). We make assumptions on what we don’t know. and we may be wrong.
When we’re doing API integration tests, we need to understand what we intend to see, and if we can tell if they are working or not. Otherwise, we’ll assume they do, based only on our expectations (which may be different between developers and testers, for example).
That’s it, fairy tale’s over. Want to know more about REST API integration tests? You should get registered to my Testing APIs with Postman course, for more fairy (or horror) tales.