Postman tests and environment based assertions

I was wondering what would be a good approach for testing API output for different user roles (== different environments). For instance a request to endpoint #1 for role A (collection-role-a.json) should return true, but for role B (collection-role-b) I expect the same endpoint to return false.

Should I handle this with different collections (besides the different environments I already have) or are there other (better) ways?

BTW I’m pretty new to Postman testing, so maybe this is a no-brainer for most of you.

1 Like

@senser76

I’m by no means an expert when it comes to Postman, however I can say I periodically rework how my collections and environments play together. I do this as things change and when I find a better way of doing things. I used to have each of my different deploy environments (Dev, Int, QA, Beta, Prod, etc) setup with each having a separate Postman environment. This would probably be much the same way you are using environments for different roles.

As we change some of the ways our APIs work I started to move more towards having anything the environments share in common placed into the Postman global variables. Then I started splitting the different deploy environments into separate folders underneath a single collection. This way I only have a single Postman collection, environment variables and global variables file. This has been beneficial when using Newman to run at time of deploy. The individual environment folder gets called per deploy environment.

The more I use Postman the more I think “Why wasn’t I doing it this way from the beginning?” What was logical at one time might not be logical in the future as we learn from our mistakes and new ways of accomplishing goals get discovered.

My hope is others will chime in on your question so you and I can see how more than just I am using Postman.

Best of luck in your discoveries,
Mick

2 Likes

If you define an environment variable to differentiate between your environments you could check in your test, which environment is being used and then test accordingly:

var env = pm.environment.get("env");
if (env === "roleA") {
    // evaluate your test
} else {
    // evaluate your test
}
2 Likes

Thanks @mick-mcbride and @tkloeber,

I guess the confusing part (at least from my perspective) is that unit tests have the test and its testcase integrated. In the case of Postman API testing, the test conditions are seperated from the actual test.

The suggestion @tkloeber makes, sounds pretty usable. Will experiment with it. I’m open to other suggestions of course.

Thanks again!

@senser76 I find it easier to keep all my variables in the 3 categories that postman has, it’s easier to build a mental map of what you’re testing:

  1. Global - values remain unchanged across environments and change less frequently (Api versions, auth_tokens etc)
  2. Environment - values change based on target (hostname, port number,
  3. Data - testing data that usually have a wide range of possibilities

In your case, i would think of user role as testing data. Because you would also want to test for junk values and the endpoint to return false. I would suggest using different data files with the same collection.

I also like @mick-mcbride idea of slicing different sub-folders to bring different context, so you could name the folder as ‘Expect role fails’ and ‘Expect role pass’. As far as you document that in the description of each subfolder and your team is comfortable to manage that consistency of test harness structure.

@harsh.parekh, thanks! Will definitely look into your suggestion!