

in the attachment I put screenshots from the same test case with a few seconds difference between each other.
I would like to know why the same test case result is 4xx, 5xx, 2xx on every try? How can I avoid it? Might it be related to waiting?
P.S. I talked to the DevOps team they said the env is stable.
Spec.js
it.only("buy a fix priced vehicle", () => {
const minPrice = 26350;
//const maxPrice = 1000000;
//const offerAmount = Math.floor(Math.random() * maxval) + minval;
const vehicleIdBuyNow = "30f269ac675813a68885ce336971d897";
const platformIdBuyNow = "yyyy";
const platformUserIdBuyNow = 0;
[![enter image description here][1]][1]
cy.request({
method: "POST",
url: "xxxxxx",
headers: {
Authorization:
"tttttt",
"content-type": "application/json",
},
body: {
id: vehicleIdBuyNow,
bid: minPrice,
auctionPlatformId: platformIdBuyNow,
auctionPlatformUserId: platformUserIdBuyNow,
},
failOnStatusCode: false,
}).then((res) => {
cy.wait(2000)
// Assertion for one by one
//cy.log(res)
//if ( res.status==404 || res.status==400 || res.status==500 || res.status==503) {
if ( res.status!=200) {
cy.log(JSON.stringify(res))
} else {
expect(res.body.id).to.eq(
vehicleIdBuyNow
);
expect(res.body.auctionStatus).contains("finished");
expect(res.body.price).to.be.equal(minPrice);
expect(res.body.winningBidPlatformId).contains(platformIdBuyNow);
expect(true).to.be.true;
expect(false).to.be.false;
//Assertion in one time
// for (const index of res.body.suggestedPrices) {
// expect(res.body.suggestedPrices[index].amount).to.be.within(
// minPrice,
// maxPrice
// );
// }
assert.isNotNull(res.amount, "is not null");
assert.isNotNull(res.body.id, "is not null");
assert.isNotNull(res.body.createdAt, "is not null");
}
})
I'm not sure async timing issues with Cypress would result in the same request coming back with those different responses.
I'd suggest closely looking at what gets sent in the cy.request and compare passing and failing scenarios. If you click on the request in the cy gui the console will have the request and response.
Sometimes making a lot of requests in your test can overwhelm your server resulting in differing responses. However, if you are seeing this problem when running the single test in isolation then that would likely rule that out.
500 tends to be an unhandled server error when trying to process the request. Maybe you could add a unique id to the header and trace it with devops to see more details.
Can your requests leave items in a certain state where repeating a test then fails?
If you're still stuck, see if you see similar behaviour with a curl/postman
Note: The cy.wait(2000) in your test, won't have any impact as the response will already have been passed into the function at that stage. It's just delaying the validation