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.
GET http://www.starshop.com/used/buy?item=1701
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.
1 Comment
David V. Corbin · January 13, 2022 at 1:37 pm
“EveryDayUnitTesting” – So that means there are ‘unit’ tests, which means that there are tests of the API where all of the data is knowable and the results can fully be verified (including things like item items that don’t exist, price changes over time, whatever).
The “trick” is to ensure that ‘integration’ tests have the same ability. If one does not have control over the back implementation of the API (as is common), then use an implementation which IS testable (it is not my responsibility to test that a puplic API implementation is actually correct – my responsibility is that I am using the API correctly).