I think the issue is the test is working with a non-existing issue (hardcoded id that isn’t from an issue created) and your logic depends on the issue to have been created.
You could bottom out at the end and send “could not update” for non-existing issues, but before that you have to check the payload against the requirement without depending on the issue existing.
The order should be:
No id send
no update field(s) sent
could not update
If you look at the network tab when you submit your code, you can see there is a missing PUT request. If you submit the demo project, you can see the extra PUT request and the order of the PUT responses.
The assert message in the console is a bit confusing because you can’t see the data from the deepEqual assert.
The first part of it that you can see, is your “could not update” response you send back, so it makes it look like it is being compared to that expected response, but I think it is actually being compared to the “no update field(s) sent” expected response. If that makes any sense.
Assert we can see:
Error: expected { error: 'could not update', …(1) } to deeply equal { …(2) }
Is really:
Error: expected {"error":"could not update","_id":"5f665eb46e296f6b9b6a504d"} to deeply equal {error: 'no update field(s) sent',_id: '5f665eb46e296f6b9b6a504d'}
That is just a guess though because we can’t actually see the assert message.
The camper really should be able to see the full assert for it to be helpful. There is also no way to know what is being compared without looking at the tests. It could be the expected tested against the response, or the response tested against the expected, there is no way to know what the order is without looking at the tests. In the case of the PUT it is the response tested against the expected, which is probably the most common order used in all the test if I was to guess.