API test automation: Would it make sense to verify POST request response with a GET request?

For example, you have a POST request and a PUT request that returns the whole json object of an entity that was created or updated. You have a get request for this.
Would it make sense to:

  1. make a post request
  2. verify response data with data object that was used to make this request
  3. then make a GET request to verify the response of POST or PUT request

IMO it should be reasonable doable, when you have tested the GET request before that. e.g. checking its result in the database.

I’m asking without having your context, you can answer for yourself:
How much are you concerned about this and what are other priorities?
Once you have looked it up by yourself manually, how much do you expect to change this?
Why would it be important to check this repeatedly by automation?

I would assume myself having more important things to check (more system behavior related) and would check this only once manual. Not writing automation for this.
I often check (“technical”) details of an API call itself most times just once and try to automate more user scenarios.

Are you a asking “How can I make this check reliable?” or “Should be I concerned that this is likely to fail?” ?
The later is hard to answer for others.

1 Like

Tbh I’m just pondering over the usefulness of such a check. The post request already returns the whole chunk, I assume it should do that by fetching data from the database and that’s exactly where the get request should the data from.

But then there’s the question if there’s a problem in the get request and in the automated checks there’s bound to be a check for it. And since its better to have a fresh data set for the get request why not pair it with the post request.

1 Like

that doesn’t matter, it just send back what it created or should have created or it can give you an ID or it can give you nothing, that doesn’t always mean it’s created in the backend, especially if it’s asynchronous.

POST - to Created
GET to verify
PUT to Create or Replace (YES create or replace, according to official restful ways)
GET to verify
Patch to Update partial data
GET to verify
DEL the item
GET to verify it’s deleted.

That’s kind of the “whole” flow, you might not have all methods but always a GET afterwards to verify imho. Especially in an Async world :smiley:

1 Like

There’s another point to this, a single source of truth.
What if the GET request has an issue?
What if the POST request is right and returning the right data but the GET request isn’t?
I think this dependent on the test design, I have code that tells me which attributes within each request are different and what value did they have. So even if the GET request is faulty, the console logs will tell me what went different between them.

Also, the only way to test the GET request is to make a POST first :sweat_smile: .

The dilemma(s):

  • A POST test that gets verified with test data because if the POST mechanism is faulty and the GET works then both their responses could match but be wrong.
  • A POST test that gets verified with test data AND GET response, this tests both of them at the same time.
  • Keep the tests atomic, go with the first approach and then a GET test with a new POST request which is followed by a GET request who’s response is verified with the test data as well so if there’s something wrong the GET, it gets revealed.

Then your test will fail on the GET request and that’s what you want right? :stuck_out_tongue:

POST /Customer
Name: Kristof
Location: Belgium

Then GET / Customer/1
Name: Bob
Location: Belgium

Then here your test will fail and that’s good. Since you expect Kristof and not Bob.

Test data:
Name: Jason
Location: Belgium

POST /Customer
Name: Kristof
Location: Belgium

Then GET / Customer/1
Name: Kristof
Location: Belgium

a possibility :sweat_smile:

You post the name Kristof which is not the same as your test data?
Then in the GET you’ll still get an error since you expect Jason right? :slight_smile:

Ah! In both cases I’m quoting the responses.
So you sent Jason to POST but got Kristof in response and also got Kristof from GET.

IF you get a response from a post request (which normally it shouldn’t besides maybe an ID) then you can validate that also but it won’t be an “official” test imho.

Yes that was the scenario in my original post:

1 Like

This has to come with a caveat YMMV, but it’s something I do all the time. The pay off hopefully comes via total upfront effort over time, but goodness when a chain of dependent tests goes wrong, the result is what I like to call a FUBAR cascade. Happened to me while I was sleeping last night. The initial API tests to create a number of accounts went TITSUP, so 85 subsequent tests failed*.

* In my defense, setting up the test data to do it the orthodox way would cross multiple databases and involve more than one ID field regime.

This is

what I referred to here

Have a check that the GET works. And not on by and API.

Yep that’s what I’ve concluded for this.
Not relying on the API responses and instead having another source of truth “test data object” or “data fetched directly from the DB” is the best way to go.

1 Like