How to implement DRY / good coding practices?

Hi all,

I have a lot of collections which are relatively similar, following this pattern.

  1. Send a POST request with a json body
  2. Send couple of GET requests and verify the results via tests

Main difference between those collections is

  • The json body of the post request
  • The test (results) of the GET requests
  • The endpoints of the POST/GET requests

This results in a lot of duplication. Basically what I´m doing is to copy a collection, and modify the body and adapt the tests, which is resulting in a lot of duplication. So when I need to modify something, I need to touch all the collections and tests.
Is there a way in Postman to implement DRY (don´t repeat yourself) and/or other coding practices/ patterns for this?

Many thanks in advance,
Christian

1 Like

Reaching out to some folks that are active in this forum to help.

@tmccann, @postman-paul540, @VincentD123, @Whersh

When we brought in the Collection and Subfolder Level elements, it was a way to extract away some of those repetitive tasks and duplication of tests.

I’m not sure if you’re currently making use of some of that functionality?

1 Like

Thanks,

my case is very similar to the comment on the blog post, currently I don´t see how prerequisite scripts/ tests on collection/ folder level would help me with that?

thanks for the mention @danny-dainton. I have to admit that I do find Postman pretty absent on nice re-use of various parts in the system, in particular code re-use, request re-use and dynamic flow execution. I have been battling with it for over a year and found some workable work-arounds. It’s all still a bit rough, but I want to start writing them up here over the next few months.

In essence, we have teams with dev’s and QA’s all adding to the same collection of grouped and alphabetised end points. Many have useful test scripts to save stuff to the globals and/or environment, but inherently it is a manual testing tool, where the user needs to perform the right sequence of steps to login, gather info, do stuff, and logout.

You’d think setNextRequest would automate something there, but alas there are conditional flows depending on responses that can not easily be predicted (eg multi-factor authentication responses that seem to appear out of the blue)

So the task was to figure out some means by which we could effectively implement a proper state machine that sends requests and then has separate response handlers for various scenarios.

I have managed to cobble something together, and it’s starting to show some dividends for us. But it’s an ugly baby right now and needs some work before I share it here.

I’m hoping to first write up something on my idea of a Postman Object Model approach, where you use a shared code library (stored in a global string) and actually write little classes in the library that know how to store themselves in globals, but hide the details. I’ve got a proof of concept working for me, and seems a cool way of being able to create persistent objects between pre-request and test scripts, as well as other requests. It effectively creating a common global scope for javascript objects.

I’d imagine someone will figure out that all this can only be done using eval, which is true, but hopefully I can convince people that that isn’t necessarily evil. I was a bit worried about storing too big a library in the globals, and that it might impact on performance. Luckily, for me, evidence suggests that’s not the case, my code library is now over 3000 lines of code, and speed doesn’t seem to be impacted in a material way.

BTW: It’s no unintended pun that it is also a P.O.M, as per the famous Page Object Model that our UI automation counterparts like to use :wink:

But bringing it back to Collection & Folder elements and keeping it DRY, my framework hinges entirely on using collection level pre-request, and test scripts. These hook into scenarios provided in an external json data file, which call internally configured user actions that contain multiple response handlers. The response handlers can cue up a further request or pass to the next step in the data file. I, pretty sure I wouldn’t managed to get it to work without being able to write a script that I can specify to run for every request, the collection & folder elements are awesome! :cowboy_hat_face:

2 Likes

@danny-dainton @chrissbaumann

EDIT: I’ve attached an example collection/environment to see it in action.
Just click the Download link at the top and import them into Postman.

Postman Collection: { "info": { "_postman_id": "ae24430b-d0c0-4b0c-91ff-90a060d4611b", "name - Pastebin.com
Postman Environment: { "id": "4d43c020-4c8c-43d8-b1ae-acaaecf7bd40", "name": "Restful Booker", - Pastebin.com

For me, keeping your tests DRY in Postman is one of the biggest challenges and it’s something that I’ve changed every year. My talk at the Postman Customer Summit in London (I think it was back in February/March time) was about this and I’m how I’m “faking” BeforeEach hooks in Postman to stop the duplication of requests.

Using the Restful Booker API that’s available for testers, I done a little proof of concept for your needs (Bear in mind, I just bashed this out in less than 30 mins after a long day of work + 1 hour commute! Ok excuses out of the way)

So! Let’s say I have this “booking” POST request that creates a booking.
I want to change the properties used in each request body that is sent.

Here’s my collection variable. I guess this can be called the request body’s “natural state” ??? So if I decide to not change anything, this is what will be POST-ed.

And I can use it in my actual POST request like this:

In the Pre-request tab for my first request, I’ll change the “firstname” value to something else.

As I said before, I bashed this out in a couple of minutes so I’m willing to bet there’s a MUCH nicer/cleaner way of updating a property value from an object that is also an environment variable…but hey, this does exactly what I want it to *shrugs

If I now send this request, the modified request body will be sent and this is confirmed in the request body returned from the POST /booking endpoint:

The cool thing about collection variables is that every request our request body will be re-assigned so we don’t have to worry about this variable being constantly mutated with every request which is nice.

If you want to test you’re always getting a 201 status code back with this POST request and assert the schema etc. you can even add these re-usable tests at the collection level.

If your tests have a pre-requisite like a “Register User” request, feel free to have a look at my code examples from faking Before/BeforeEach hooks in Postman.

Hopefully, you were able to get some value from this reply.

4 Likes

Hey @postman-paul540,

many thanks, I think I´m getting the idea, looks like a quite smart approach to me.

I think for it to be usable for me, I would need to re-organize my collections a bit: At the moment every use case or variation of a use case is a collection.
To be able to use your approach, I would need to group similar use cases maybe in collections, where I use folders for the different variations; thus I would be able (to follow your example) to set the request body on collection level, and then modify it as needed in the requests in the folder, no?
Otherwise i think I would not really benefit from your approach.

Best,
Christian

Sounds about right.
I’m sure there are many different ways you can organise your collections to make them DRY.
I think I do something similar in my collection for our Customer Returns project, where every “Test Scenario” would be a collection.

I have 4 collections at the top level for each “item” type.

  • Customer Return Related Tests
  • Tests relating to the product that is returned to the warehouse (URN = Unique Reference Number)
  • Tests relating to our “Putaway” process where items are shelved back in our warehouse after being returned.
  • And finally, tests relating to creating a Supplier Return (A return that is down to the supplier’s responsibility)

So if we look in the “[B] URNs” collection, a prerequisite for every sub-collection in my URNs collection is to create a brand new URN in our database. This used to be a POST request that was added at the top of every sub-collection, which was a nightmare to maintain.

So I added a “Before Each URN” collection where I have the POST request to create a URN. So I’ve cut down from reusing the same request 10 times, to once. :+1:

I’m doing this by using the “postman.setNextRequest” command a lot - this, to me, is one of Postman’s most valuable methods that isn’t talked about enough.

2 Likes

This sounds exactly like what I was looking for! Awesome, many thanks! :slight_smile:

Will give it a try!

2 Likes

Ha sweeeet!

I have some more examples about the whole BeforeEach thing in this post here:

1 Like

Nice work guys. Sorry I don’t have a ton to add to this as its not something I run into a lot most days.

However I will add in that this is something that I want to see improve in future versions of the application as its an area that I get grilled on very often by my development teams when on-boarding or evangelizing the product and is the 1st thing thats pointed out as a Con for using the product.

There is definitely a need to be able to add reusable code that act at a global level and give the product a more complete functional feel. I know there are many requests already in the community for some feature like this already, that being said. As we can see above there are ways around this and some best practices that can be put in place to get the coverage needed.

One thing I love about the Postman product is there are always lots of ways to get the same outcome you are looking for and some awesome people willing to jump in and help each other out.

5 Likes

How are you getting on @chrissbaumann? Have you managed to improve your tests at all? :slight_smile:

Thanks for asking. :slight_smile:

Step by step I´m doing, but it somehow feels “wrong” and “hacky”, like you have to use workarounds for a lot of things that are standard, when using a programming language.
I think for the next project we might go for a framework like REST Assured or similar.

@chrissbaumann Yes, agreed. Workarounds are still workarounds. :slight_smile:

We have plans for improving reusability in Postman, but they are still in a very early phase to have something concrete to show at this point. So far, we have plans for improving collection runs to be able to include multiple collections. It’s added as a roadmap item here:

Also worth mentioning, there is an issue in Postman’s GitHub issue tracker where this has been an ongoing discussion for a long time. Recently, @abhinav explained the challenge in a comment there:

This definitely does not address your present issue. I just wanted to let you know that we have it on our radar and are working towards it.

2 Likes

That sounds indeed great, it would help me a lot to reduce duplication.

1 Like