Using pm API, I wish to update my test name on the fly based on the response/calculation.
Usage: want to make final test report more intuitive and useful by appending the important information on the Test name as it’s visible i the report.
right now, dealing by appending the full response in the function call itself but that gets huge at time.
pm.test(“TEST NAME”+pm.response.json(), () => {
//
});
I used to do this back in the day by using variables to shorten the JSON path in the test name.
If the below response is returned:
{
"people": [
{
"name": "Paul",
"age": 29
}
]
}
My Tests tab would look like this:
const body = pm.response.json();
const statusCode = pm.response.code;
pm.test("Expected 200 Satus Code to be returned", function() {
pm.expect(statusCode).to.equal(200);
});
pm.test("Expect at least 1 person to be returned", function() {
pm.expect(body).to.have.property("people");
pm.expect(body.people).to.have.a.lengthOf.least(1);
});
if(body.people.length > 0) {
const people = body.people;
// Test will read: "Expect Paul's age to be 29"
pm.test("Expect Paul's age to be " + people[0].age, function() {
pm.expect(people[0]).to.have.property("age", 29);
});
// Or use backticks if you prefer
pm.test(`Expect Paul's age to be ${people[0].age}`, function() {
pm.expect(people[0]).to.have.property("age", 29);
});
// Or use variables to shorten the path
const ageOfPaul = people[0].age;
pm.test(`Expect Paul's age to be ${ageOfPaul}`, function() {
pm.expect(ageOfPaul).to.equal(29);
});
};
I stopped doing this though in case the property or value wasn’t returned so the test would say something like: “Expect Paul’s age to be undefined” which isn’t helpful.
I assume it’s not recommended to do this though as you should know what the value/result of the test will be upfront. Correct me if I’m wrong on this though.
Hey @p00j, something like this can be achieved using Collection/Folder level test scripts (... => Edit). Let us take an example to understand this better.
Consider the case where you have two requests each of which return an user object. You would like to use the name of the user returned in each request in your test name. The response look like:
{
"user": {
"name": "luffy",
"username": "Kaizoku no ō"
}
}
Now since the parent level test scripts get executed after each request they include, you can write some common parsing logic there to use the response returned by each request.
So if I consider, each request returns the above user object, I can write something like:
const response = pm.response.json(),
user = response.user;
pm.test(user.name + ' additional string', function () {
// test code goes here
});
This is just a basic example to demonstrate how you can build more complex workflows using the Collection/Folder level scripts, give it a shot and let me know if you need additional help.
Thanks @deepak.pathania , however it’s exactly same what i’ve shown in my example. I’m looking for a method to change test name from within my test
Eg.
pm.changeTestName(…);
So that I have better control from my test, as I can have many expects and Loop logics in my test and really won’t know the exact key upfront.
Eg. my response is a list of arrays of objects (> 50) and I wish to assert if one object contains my key. And only when the assert fails, I want to attach whole list’s truncated, meaningful log to the test name so that I can identify the reason quickly without needing to go to postman logs and search for response etc. And hence I wish to have a way to change the test name on the fly instead of logging the whole response for each call in success cases as well.
cc: @postman-paul540
Update For a workaround, I started using Chai framework’s beauty, attaching the required message in assert statement, which comes only when the test fails.
Eg.
let response = pm.response().json(); expect(response).to.have.member('blah',response was =${response});
Something like pm.changeTestName() doesn’t exist right now, you can open a feature request on out GH issue tracker.
On a side note, I don’t think updating the test name to reflect what went wrong in an assertion is a great idea. I understand that the assertion failure logs can be daunting but I feel the workaround you mentioned combined with meaningful test suite descriptions make more sense to handle this use case.
If your test description clearly mentions the scenario under which it fails and you log only for failure which you’re doing through the workaround, then you can make out what went wrong pretty quickly, without getting lost in the logs.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.