Reuse the same request inside several collections

[KumG]

Is there a way to reuse the same request in several collections ? I didn't find how.

For example, I need to call a login method before any other method call, and I want my collections of tests to be independent. If I duplicate the login request, I will have to edit all the requests if I need to change something.

[rmnrdi]

Not being able to re-use test code is a huge limitation.

How do you expect companies to maintain a large base of API tests?

Tests execute at a given level for every request under that level. Say collection level. So if you don't want to run certain tests, you have to create a new collection that omits those tests or start using folders. Doesn't matter, we still have to copy and paste tests.

If we can't abstract out the code to a higher level and PM forces us to manage tests by using the collection, folder, request hierarchy, you're essentially forcing us to repeat our code.

Which is bad M'kay.

Why is it not possible to allow us to create code files for our collections to "consume" like libraries? If you're worried about dependencies, then put restrictions on function nesting or whatever you need to.

We need ONE place to put our code so if we need to change the code, we do it in ONE place.

Say I have 10 out of 100 tests that need to be altered in some way. How do we even find where they are?

Having said that, maybe you guys have a way to search across all collections, but that's not the main point.

The point is, we still have to track down those 10 tests and change them one by one. No bueno!

Rant complete....

Thank you, -R

[JohnArrowwood]

The use case you are not considering is Quality Assurance of an endpoint.

To thoroughly test, both positive and negative and boundary conditions, etc., requires calling the same endpoint over and over and over again. If the test requires pre-test setup and post-test tear-down, that means creating a collection for each test case. If something about the endpoint changes, we have to modify every instance of that call. If that call is used in setup and tear-down of other endpoint test cases, the total number of places that have to be changed may number in the hundreds, or in some cases thousands. The antithesis of DRY.

The idea that the problem is solved with swagger is questionable, to say the least, but even if it is, that means that in order to use your tool for some API, if that API does not already have a Swagger definition, then someone has to build one. In my case, when I first raised this request, that was not an option. So your solution isn't a solution.

Now let's compare that to what I do with my Java+RestAssured test code.

For each endpoint, I define a class with a fluent interface. I have both a "Control every detail" version and a "utility" version of how I interact with that interface. In my test cases, I invoke the class to build the request with whatever specific parameters I need. If the test case is just using the endpoint as part of setup or tear-down, I use the utility version of the interface, which is more concise. When the test case is explicitly testing the endpoint, then I use the more verbose version of the interface. End result: DRY.

Had Postman supported DRY development of test cases, I might have stuck with it, and you would have recurring revenue from not just one team, but now two. But because you don't see the utility of using your tool for testing an API in any but the most rudimentary way, you have lost me and my team mates as a customer. And judging from what others are saying, you either stand to lose, or have already lost, quite a few others, also.

And your reaction? It's a feature that is not needed.

You're probably right. You don't need real programmers applying best practices of programming to their use of your tool, using it for quality assurance purposes. You have other, less demanding customers you can service. But speaking on behalf of the class of customer you are discounting, we're sorry you feel that way, guess I won't be the only one who is forced to abandon Postman.

On Tue, Sep 15, 2020 at 11:52 AM Kin Lane notifications@github.com wrote:

I get what is being asked here completely. I am just stating I don't think folks are considering the big picture of re-use (ie. OpenAPI as truth of that reuse). How difficult what is being asked is across 12M use cases, and I am unconvinced of it being a blocker, and something folks will walk away from postman from if they can't do (which folks love to throw out). Each request has a unique ID and there is an API reuse. Each request has an OpenAPI truth, and you can reuse across collections, and even validate that reuse -- if it is something that will push you to walk away from without showing a single use case via API, I am left feeling like your isn't a real problem.

This is why APIs exist to demonstrate what should be possible in app. It just is frustrating to be working overtime showing many different use cases to my team to influence the future of the UI, only to have people say "I am leaving cause you won't do this" (when we are doing it), without demonstrating their use case. It's cool. I'll keep doing the work and influencing the road map.

I'll say it again, and see if it sticks, "there is reuse of API requests right now" It is done with OpenAPI + Swagger -- then you can generate multiple mock, doc, and test collections from those "truths". You can validate those if they break, and regenerate them if they break. This thread is ONLY focused on collection to collection reuse. Show me a use case on why this is the right way, and I will influence the road map. I am looking at the big picture, this thread is just a single slice of that picture.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/postmanlabs/postman-app-support/issues/1535#issuecomment-692807491, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3XLRIDQHTILATLO4LLNSLSF6ETLANCNFSM4BTAAD7A .

[kinlane]

This thread continues to amaze me at how confrontational the responses are, and how often "leaving Postman" is mentioned as we work through this complex issues, and are looking for feedback. With that said, I'm not going to address everything mentioned above--it just isn't conducive to forward motion. I will just say:

1) OpenAPI Driven Reuse - We are continuing to drive OpenAPI contract reuse across many collections. So generating many collections (with reuse of requests) across the API lifecycle, as well as API integration. With validation of these collections against these OpenAPI contracts -- helping address keeping all of your reused requests in sync with a central contract for when that contract changes. I STRONGLY recommend you look at OpenAPI contracts as core of your reuse, collection only reuse will not scale across the lifecycle. But I understand that is where many people live. 2) Postman on the Web - Every collection has a URL now, and you can reference a collection, individual requests, as well as examples via a URL. Making them more easily reference-able, reusable, and executable outside of the desktop application. This will be the foundation for next generation API request reuse beyond the narrow slice of doing it within a collection. 3) Collection Request Reuse - Now that we have delivered Postman on the web, I have seen work in the road map (internally) regarding individual collection referencing and reuse. I had hoped to get more of these "blocker" use case examples from this thread explained, but we'll go ahead and build based upon existing customer feedback and other relevant issues.

It has been a long road to get here. Once I have a feature release to announce around this I will add to this thread. One of the challenges with this thread is I think there are many views of what Postman is on this thread are very locked into the fact that it is just a testing tool. I look forward to offering up collection request reuse in an upcoming release, not just for testing, but for use across the entire API lifecycle.

Thanks everyone!

[rmnrdi]

@kinlane Why are you putting "blocker" in quotes?

Can we technically make tests without code re-use? "Yes" Would it be far better and more maintainable to have code re-use then repeating code? Yes.

I don't know if we can articulate exact use cases for code re-use because it is such a fundamental part of coding.

It would be like asking "Why do you need functions?"

It has the same answer, so we don't duplicate our code.

The use case is "Everything we do"

Thank you for your detailed response above, we appreciate your point of view.

[andyg101]

@kinlane I understand the approach you are proposing I think with using Open API to generate collections but what about the people who actually use the Postman GUI (which is great) to pull together their test case? Are you suggesting we shouldn't be using that and we should be first authoring our requests in Swagger?

@a85 I appreciate the point about complexity but my suggestion would be that perhaps this complexity is introduced by you treating each request as an identifiable instance with a UUID and tying it into the dependency graph. Wouldn't another option be to provide more of a re-usable template functionality where you define a template request once and use that as the basis for your individual instances? I'm not dismissing your point about complexity here, I haven't looked at/understood your code. I'm just saying that it sounds like you could come at it a different way.

[a85]

@andyg101 You are right. Kin and my point was that there are lots of different kinds of reusability related issues. Overall we do want everyone to reuse things directly using the Postman GUI.

We are looking at including introducing a new abstraction (a "flow")that builds on top of existing collection functionality. Basically existing collection requests become the template and users can then orchestrate "flows" to define how these requests can fit together. That will allow for multiple requests to be used in the same flow, requests from different collections to be used together, along with flow control logic (looping/branching) to be introduced independently. The new version of Postman's Collection Runner uses this internal flow abstraction already. We are looking at how best to represent it in the UI. We are also considering this new runner to have a more drag/drop feel that allows for faster orchestration of test cases.

Of course if you want to run an entire collection or a folder, you'd be able to drag/drop that into a flow too. There are still some elements to be solved for here but I thought I'd share our ideas so everyone is aware that we are taking this seriously.

[andyg101]

@andyg101 You are right. Kin and my point was that there are lots of different kinds of reusability related issues. Overall we do want everyone to reuse things directly using the Postman GUI.

We are looking at including introducing a new abstraction (a "flow")that builds on top of existing collection functionality. Basically existing collection requests become the template and users can then orchestrate "flows" to define how these requests can fit together. That will allow for multiple requests to be used in the same flow, requests from different collections to be used together, along with flow control logic (looping/branching) to be introduced independently. The new version of Postman's Collection Runner uses this internal flow abstraction already. We are looking at how best to represent it in the UI. We are also considering this new runner to have a more drag/drop feel that allows for faster orchestration of test cases.

Of course if you want to run an entire collection or a folder, you'd be able to drag/drop that into a flow too. There are still some elements to be solved for here but I thought I'd share our ideas so everyone is aware that we are taking this seriously.

Thanks @a85 . It would be good to understand if you are thinking about using these flows being supported in newman too.

[a85]

Yep. Newman will execute flows the same way and both the runner and Newman will be backward compatible.

[plotnikov-digicode]

5 years and this still isn't implemented?

[fransf-wtax]

@andyg101 You are right. Kin and my point was that there are lots of different kinds of reusability related issues. Overall we do want everyone to reuse things directly using the Postman GUI. We are looking at including introducing a new abstraction (a "flow")that builds on top of existing collection functionality. Basically existing collection requests become the template and users can then orchestrate "flows" to define how these requests can fit together. That will allow for multiple requests to be used in the same flow, requests from different collections to be used together, along with flow control logic (looping/branching) to be introduced independently. The new version of Postman's Collection Runner uses this internal flow abstraction already. We are looking at how best to represent it in the UI. We are also considering this new runner to have a more drag/drop feel that allows for faster orchestration of test cases. Of course if you want to run an entire collection or a folder, you'd be able to drag/drop that into a flow too. There are still some elements to be solved for here but I thought I'd share our ideas so everyone is aware that we are taking this seriously.

This sounds great.

What I basically want is to have a collection of requests that are the source of truth. Then completely apart from that (not on a tab of the request) I want to be able to define tests that use requests from my collection of requests, possibly calling them in different orders and with different variables. And then doing assertions on the result.

Really hope to see a beta version of this that we can start playing around with.

At this point my two options for API testing seem to be Postman and SoapUI. SoapUI has a horrible buggy UI but already can do tests like this. Postman has a much smoother API and is much more widely used (especially for REST APIs) but right now the testing infrastructure is not at a point where I can actually use it for a sizeable real life project without lots of duplication. I really hope I can make a wholehearted choice for Postman soon when this is released.

[pbarnum]

@kinlane Is there a branch that exists with the latest work? I'm wondering if I can help write code or test current solutions.

[srbangre]

+1

[henrychancalabrio]

In my company we are using "Postman as a REST Service" I wrote an REST endpoint that takes in a collection as a param as well as a param or POST body for an environment. If anyone is interested in what I did, let me know.

Cheers, Henry

[corwestermaniddink]

In my company we are using "Postman as a REST Service" I wrote an REST endpoint that takes in a collection as a param as well as a param or POST body for an environment. If anyone is interested in what I did, let me know.

Cheers, Henry

I'm interested, but let do that out of this topic ;-)

[ztzsws1]

@andyg101 You are right. Kin and my point was that there are lots of different kinds of reusability related issues. Overall we do want everyone to reuse things directly using the Postman GUI.

We are looking at including introducing a new abstraction (a "flow")that builds on top of existing collection functionality. Basically existing collection requests become the template and users can then orchestrate "flows" to define how these requests can fit together. That will allow for multiple requests to be used in the same flow, requests from different collections to be used together, along with flow control logic (looping/branching) to be introduced independently. The new version of Postman's Collection Runner uses this internal flow abstraction already. We are looking at how best to represent it in the UI. We are also considering this new runner to have a more drag/drop feel that allows for faster orchestration of test cases.

Of course if you want to run an entire collection or a folder, you'd be able to drag/drop that into a flow too. There are still some elements to be solved for here but I thought I'd share our ideas so everyone is aware that we are taking this seriously.

Sounds great and do you have any release plan about this? @a85

[dgliddenIDF]

Leaving a comment for another request for this feature.

We have a good-sized collection of tests against the application we primarily use, but use-cases for different clients can be vastly different and the ability to "link" tests into different groups would be extremely beneficial to being able to build a generic set of tests that can be put together in different ways depending on use-case.

[ManiacDC]

We're running into technical limitations with postman and newman since this feature is not available. We have a collection of tests with approximately 1800 requests in it.

The collection is broken up into folders, where each folder is unrelated to the other folders; however, there is a common setup and cleanup folder that runs before and after each of the other folders. We use setNextRequest to navigate to/from these setup/cleanup folders as necessary.

We've found that Newman is using over 1.5GB of ram when running this collection during CI, which is causing issues for our CI containers. We've had to bump up the memory limits on these containers numerous times as we keep hitting the limit as we add new requests in.

We've found that the memory usage resets when running a new collection in newman, so if these were separate collections, we wouldn't have memory issues. However, there's no way to share these setup/cleanup requests without turning them into code that's stored in global variable, which isn't ideal. Being able to use requests across collections would solve this.

(Alternatively, so would addressing the huge memory usage in newman and postman... we have no idea why the memory usage is so huge)

[corwestermaniddink]

We're running into technical limitations with postman and newman since this feature is not available. We have a collection of tests with approximately 1800 requests in it.

The collection is broken up into folders, where each folder is unrelated to the other folders; however, there is a common setup and cleanup folder that runs before and after each of the other folders. We use setNextRequest to navigate to/from these setup/cleanup folders as necessary.

We've found that Newman is using over 1.5GB of ram when running this collection during CI, which is causing issues for our CI containers. We've had to bump up the memory limits on these containers numerous times as we keep hitting the limit as we add new requests in.

We've found that the memory usage resets when running a new collection in newman, so if these were separate collections, we wouldn't have memory issues. However, there's no way to share these setup/cleanup requests without turning them into code that's stored in global variable, which isn't ideal. Being able to use requests across collections would solve this.

(Alternatively, so would addressing the huge memory usage in newman and postman... we have no idea why the memory usage is so huge)

Some thoughts:

1. If you have that amount of requests in 1 collection, then: a. Your test is taking to long for use in a CI/CD release strategy as quality gate in a pipeline. b. Your testobject is one huge old dragon, instead of scs/microservices => architectural finding c. You have too much testauto on the api level in your total testauto strategy. d. The way you setup and organized your Collection can be setup smarter. Console logging everything on info or even debug level can ask allot of resources. e. The requests/response body’s are huge => finding!

2. Newman has the ability to run only 1 folder in your collection, maby that will help to control the amount of resources, temporary fix.

[ManiacDC]

Some thoughts:

1. If you have that amount of requests in 1 collection, then: a. Your test is taking to long for use in a CI/CD release strategy as quality gate in a pipeline. We don't have CD (yet) b. Your testobject is one huge old dragon, instead of scs/microservices => architectural finding c. You have too much testauto on the api level in your total testauto strategy. d. The way you setup and organized your Collection can be setup smarter. Console logging everything on info or even debug level can ask allot of resources.

We definitely have some improvement on the roadmap for how and what we test

e. The requests/response body’s are huge => finding!

Unfortunately, that's not it. Our requests/responses are relatively small, nothing should really be more than 1KB. I did do some profiling of newman yesterday, though. I checked a few times when memory was around 500MB, 700MB, 1GB. The (string) allocations were over 1/3 of the memory usage and the majority of those appeared to be loaded code. There were over 900,000 (string) allocations at one point, all retained memory that could not be garbage collected.

2. Newman has the ability to run only 1 folder in your collection, maby that will help to control the amount of resources, temporary fix.

Thanks for the idea, but unfortunately, Newman has the same limitations as Postman does. If you run a single folder, you can't call a request from another folder in that same collection. As such, I can't call my setup/cleanup code from that single folder.

[corwestermaniddink]

Some thoughts:

1. If you have that amount of requests in 1 collection, then: a. Your test is taking to long for use in a CI/CD release strategy as quality gate in a pipeline. We don't have CD (yet) b. Your testobject is one huge old dragon, instead of scs/microservices => architectural finding c. You have too much testauto on the api level in your total testauto strategy. d. The way you setup and organized your Collection can be setup smarter. Console logging everything on info or even debug level can ask allot of resources.

We definitely have some improvement on the roadmap for how and what we test

e. The requests/response body’s are huge => finding!

Unfortunately, that's not it. Our requests/responses are relatively small, nothing should really be more than 1KB. I did do some profiling of newman yesterday, though. I checked a few times when memory was around 500MB, 700MB, 1GB. The (string) allocations were over 1/3 of the memory usage and the majority of those appeared to be loaded code. There were over 900,000 (string) allocations at one point, all retained memory that could not be garbage collected.

1. Newman has the ability to run only 1 folder in your collection, maby that will help to control the amount of resources, temporary fix.

Thanks for the idea, but unfortunately, Newman has the same limitations as Postman does. If you run a single folder, you can't call a request from another folder in that same collection. As such, I can't call my setup/cleanup code from that single folder.

I really think this is more a Newman issue then Postman related.

a. Raise a ticket at https://github.com/postmanlabs/newman/ to get this analyzed. b. Their is a feature request at Newman about restricting the memory usage: https://github.com/postmanlabs/newman/issues/2632

[ManiacDC]

I don't think it's a newman issue, but probably one (or more) of the underlying libraries such as postman-runtime. The memory usage is that high in both postman and newman. I will open an issue though, thanks.

[andyg101]

Unfortunately we've had to move away from Postman as per my previous posts and found a solution that has a much lower maintenance burden.

[samsamm777]

Unfortunately we've had to move away from Postman as per my previous posts and found a solution that has a much lower maintenance burden.

Curious to know what your alternative solution is?

[elazar]

They aren't even supported in the same collection yet, and that issue has gotten about as much development as this one.

[ManiacDC]

They aren't even supported in the same collection yet, and that issue has gotten about as much development as this one.

Those specific scenarios have tons of workarounds. Folders, setNextRequest, functions, etc. I could see why that issue wouldn't have much traction.

[andyg101]

Unfortunately we've had to move away from Postman as per my previous posts and found a solution that has a much lower maintenance burden.

Curious to know what your alternative solution is?

@samsamm777 - We use the Cypress cucumber pre-processor and JavaScript / Typescript implementations of test code combined with some code to send http requests to our application. This seems to work pretty well and allowed me to re-use most of the test code we had written in postman with just a little tweaking. Not quite as powerful or user friendly as using postman but it fits our needs and leaves us with a much smaller maintenance overhead.

[Mehrdad-Dadkhah]

+1

[josephbleau]

+1

I maintain a collection that I treat as my "source of truth" for all of my requests and for every new scenario I want to test I find myself copy+pasting the appropriate requests into a new collection in order to script them. At my scale this works well enough, but I would really love to see request reuse as a first class feature in Postman.

[GreyYar]

+1 I have several collections to run, and the same request inside of each one. If request body changes during development, it becomes painful to go through every request in different collections to fix.

[RajGoodF]

+1

[ryubal-sh]

8 years later, seems like this feature is not coming. That's unfortunate.

[malvikach]

@ryubal-sh We are conceptualizing some ideas for this.

I would like to understand your workflows a bit better. Are you up for a short discussion? Please feel free to drop me a note at malvika.chaudhary@postman.com or block some time with me using this link.

[dwightdhooge]

Any update on this? Would be nice to re-use a same f.ex login request in multiple collections. So when we change something to the login request, is is reflected everywhere. Now we need to duplicate the login for each collection to be able to run each collection separately

[domthebomb]

This is really disappointing to read. Im currently evaluating Postman for automating our backend API unfortunately this duplication of common requests like login makes me feel like the maintenance will become a real bone of contention for small companies like ours we don't have the resource to be able to spend the extra time on maintenance. so posting this in the hope that Postman will see and help support smaller businesses by providing this maintenance-saving feature.

[sudhirbits]

Needed for the test infra to be DRY. Not having this capability is a big put off.

[EduardoPazz]

🆙

[malvikach]

Hi All,

We would love to learn more from you regarding this problem. Please feel free to drop me a note at malvika.chaudhary@postman.com or block some time with me using this link.

Thanks Malvika

[krispenner]

+1 for workspace level pre-request script.

[RosieColler]

This would be a great addition. I have a pre-request script that grabs an access token from our identity server. As our company uses this across our APIs I want the same script on all collections (we have a collection for each API).

[RichardForshaw]

This issue has been open for so long. I originally commented 6 years ago.

As a result we are now moving away from Postman for collection-based testing. We will only use it for exploration.

[kkindler23]

This issue has been open for so long. I originally commented 6 years ago.

As a result we are now moving away from Postman for collection-based testing. We will only use it for exploration.

hi @RichardForshaw or anyone that may have knowledge of this- we're facing exact same need/concern. Anyone have a good alternative solution either inside of postman or beyond? Besides request shared requests/maintenance postman seems to have everything else needed to chain api's for test automation. Thanks in advance

[giridharvc7]

Folks, we are working on this, and we'll have some updates in the coming weeks. We highly appreciate your patience.

The solution looks something like this:

• You can save code in a central repository inside postman. Think functions and objects.
• You can reference this code in your requests across workspaces, and collections.

This would help you write business logic and tests in a single place and reference them in multiple places (Requests, collections across workspaces)

We'll keep you posted here as we progress.

[ChristianSauer]

That's exactly what you said in 2022 or so, see above But I guess the useless team features where more important. Anyway, I'm doing resting using homegrown stuff and untlelij for rest

Gesendet von Outlook für Androidhttps://aka.ms/AAb9ysg

---

From: Giridhar @.> Sent: Thursday, February 29, 2024 6:45:20 AM To: postmanlabs/postman-app-support @.> Cc: Christian Sauer @.>; Mention @.> Subject: Re: [postmanlabs/postman-app-support] Reuse the same request inside several collections (#1535)

Folks, we are working on this, and we'll have some updates in the coming weeks. We highly appreciate your patience.

The solution looks something like this:

• You can save code in a central repository inside postman. Think functions and objects.
• You can reference this code in your requests across workspaces, and collections.

This would help you write business logic and tests in a single place and reference them in multiple places.

We'll keep you posted here as we progress.

— Reply to this email directly, view it on GitHubhttps://github.com/postmanlabs/postman-app-support/issues/1535#issuecomment-1970451237, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABXKCSLEENT326EM4W6KSP3YV277BAVCNFSM4BTAAD7KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJXGA2DKMJSGM3Q. You are receiving this because you were mentioned.Message ID: @.***>

[kkindler23]

Folks, we are working on this, and we'll have some updates in the coming weeks. We highly appreciate your patience.

The solution looks something like this:

• You can save code in a central repository inside postman. Think functions and objects.
• You can reference this code in your requests across workspaces, and collections.

This would help you write business logic and tests in a single place and reference them in multiple places (Requests, collections across workspaces)

We'll keep you posted here as we progress.

Just to be clear- the need would be a request residing in a single place then some type of clear reference to that same across one to many collections in the same workspace. make a change to the request & all references instantly pick that change up upon execution. kind of like the reuse of a cucumber step. want to use PM to chain api requests. think testcase1=login, do A,B; testcase2=login, do C,D, testcase3=login,do E,F ,etc - modify & save login up top and that funnels to all

Please inform/be clear if this will occur very near future** we are looking for a company test automation replacement solution to browser testing. going to assume not, but yet have hope as we love working in PM. thanks

[arpadffy]

Hi,

I do not like to be pessimistic, but this thread has been open for many years... nothing happened

... and now you write the following?

Folks, we are working on this, and we'll have some updates in the coming weeks. We highly appreciate your patience. The solution looks something like this:

• You can save code in a central repository inside postman. Think functions and objects.
• You can reference this code in your requests across workspaces, and collections.

I am sorry, but this is not a solution that we - users - would like to see.

A test case (use case) is a collection of ordered API calls, like:

collection testcase 1:

• login
• do one
• do two
• logout

collection testcase 2:

• login
• do one
• do three
• logout

where (for example) the login API uses the same parameters in all collections and the behaviour is driven via environment and global parameters

A central repository of the API calls (with all pre-req and post scripts, tests) would help, but not a central collection of arbitrary code. We would like to reuse the very same API calls - and in case the API (like login) changes - all the testcases would start to use the new API call without any change in the collections - as these collections are usually run with newman in batch mode.

we are working on this, and we'll have some updates in the coming weeks

I will not hold my breath, I am sorry :(

Regards, Z

On Thu, 29 Feb 2024 at 14:40, kkindler23 @.***> wrote:

Folks, we are working on this, and we'll have some updates in the coming weeks. We highly appreciate your patience.

The solution looks something like this:

• You can save code in a central repository inside postman. Think functions and objects.
• You can reference this code in your requests across workspaces, and collections.

This would help you write business logic and tests in a single place and reference them in multiple places (Requests, collections across workspaces)

We'll keep you posted here as we progress.

Just to be clear- the need would be a request residing in a single place then some type of clear reference to that same across one to many collections in the same workspace. make a change to the request & all references instantly pick that change up upon execution. kind of like the reuse of a cucumber step. want to use PM to chain api requests. think testcase1=login, do A,B; testcase2=login, do C,D, testcase3=login,do E,F ,etc *Please inform/be clear if this will occur very near future*** we are looking for a company test automation replacement solution to browser testing. going to assume not, but yet have hope as we love working in PM. thanks

— Reply to this email directly, view it on GitHub https://github.com/postmanlabs/postman-app-support/issues/1535#issuecomment-1971167551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG7S6QDALY2CKZANWQP3HZLYV4XVNAVCNFSM4BTAAD7KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJXGEYTMNZVGUYQ . You are receiving this because you commented.Message ID: @.***>

[ChristianSauer]

It's funny, but while I would never pay for useless collaboration features I would pay for good collection reuse....

Gesendet von Outlook für Androidhttps://aka.ms/AAb9ysg

---

From: Zoltan Arpadffy @.> Sent: Saturday, March 2, 2024 12:29:26 PM To: postmanlabs/postman-app-support @.> Cc: Christian Sauer @.>; Mention @.> Subject: Re: [postmanlabs/postman-app-support] Reuse the same request inside several collections (#1535)

Hi,

I do not like to be pessimistic, but this thread has been open for many years... nothing happened

... and now you write the following?

Folks, we are working on this, and we'll have some updates in the coming weeks. We highly appreciate your patience. The solution looks something like this:

• You can save code in a central repository inside postman. Think functions and objects.
• You can reference this code in your requests across workspaces, and collections.

I am sorry, but this is not a solution that we - users - would like to see.

A test case (use case) is a collection of ordered API calls, like:

collection testcase 1:

• login
• do one
• do two
• logout

collection testcase 2:

• login
• do one
• do three
• logout

where (for example) the login API uses the same parameters in all collections and the behaviour is driven via environment and global parameters

A central repository of the API calls (with all pre-req and post scripts, tests) would help, but not a central collection of arbitrary code. We would like to reuse the very same API calls - and in case the API (like login) changes - all the testcases would start to use the new API call without any change in the collections - as these collections are usually run with newman in batch mode.

we are working on this, and we'll have some updates in the coming weeks

I will not hold my breath, I am sorry :(

Regards, Z

On Thu, 29 Feb 2024 at 14:40, kkindler23 @.***> wrote:

Folks, we are working on this, and we'll have some updates in the coming weeks. We highly appreciate your patience.

The solution looks something like this:

• You can save code in a central repository inside postman. Think functions and objects.
• You can reference this code in your requests across workspaces, and collections.

This would help you write business logic and tests in a single place and reference them in multiple places (Requests, collections across workspaces)

We'll keep you posted here as we progress.

Just to be clear- the need would be a request residing in a single place then some type of clear reference to that same across one to many collections in the same workspace. make a change to the request & all references instantly pick that change up upon execution. kind of like the reuse of a cucumber step. want to use PM to chain api requests. think testcase1=login, do A,B; testcase2=login, do C,D, testcase3=login,do E,F ,etc *Please inform/be clear if this will occur very near future*** we are looking for a company test automation replacement solution to browser testing. going to assume not, but yet have hope as we love working in PM. thanks

— Reply to this email directly, view it on GitHub https://github.com/postmanlabs/postman-app-support/issues/1535#issuecomment-1971167551, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG7S6QDALY2CKZANWQP3HZLYV4XVNAVCNFSM4BTAAD7KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJXGEYTMNZVGUYQ . You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHubhttps://github.com/postmanlabs/postman-app-support/issues/1535#issuecomment-1974770721, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABXKCSPDA6YPZN6TJ3HRDBTYWGZZNAVCNFSM4BTAAD7KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJXGQ3TOMBXGIYQ. You are receiving this because you were mentioned.Message ID: @.***>

[johndegey]

Folks, we are working on this, and we'll have some updates in the coming weeks. We highly appreciate your patience.

The solution looks something like this:

• You can save code in a central repository inside postman. Think functions and objects.
• You can reference this code in your requests across workspaces, and collections.

This would help you write business logic and tests in a single place and reference them in multiple places (Requests, collections across workspaces)

We'll keep you posted here as we progress.

Hello,

Any timeline for this ?

Best

[chris-gotenna]

Bump

[jakegrabowski]

beep

[sebastianvirlan-plt]

Buzz