-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"orderOfOperations" doesn't honor "*" wildcard #122
Comments
@Fetchinator7 It is an interesting request. The goal of the ordering operations was to provide a way to change the order of specific requests, to facilitate simple request scenarios or reordering then what has been set in the OpenApi doc. The wildcard option was indeed not foreseen. The order of operations option, would only rearrange the specific request and maintain the order of the untouched items, within the folder. Mostly to overcome strangely sorted OAS documents. Some questions, that will help us to better understand your use-case: |
I guess there was a misunderstanding on my part. I thought ordering requests by type was supposed to work for all routes so this would have been a bug. BTW, congrats on being being featured in OpenAPI.Tools. I'm really excited to see where this project goes! To answer your questions:
As far as my use-case goes: I've been using Dredd for openapi testing but I would rather be using this project. However, Dredd allows you to sort requests "in a sensible way" which helps with my minimal per-test configuration. Per Dredd's documentation: "Sorts requests in a sensible way so that objects are not modified before they are created. POST, GET, HEAD, PUT, PATCH, LINK, UNLINK, DELETE, TRACE." Sorting requests by type is helpful because since I start with an empty db every time by running the POST request first the resource is there for a GET request vs the default order where a GET going first would result in a 404 since no resources exist yet. Expanding on the new feature: consecutive "happy" and "unhappy" requestsThis is similar to sorting in general but helps with what may be an edge case of a 409 unique value error: Currently the "unhappy" assertions happen after the "happy" ones because of the folder structure but it'd be nice if they were consecutive for automatic 409 unique value errors. (Like if "email@email.com" is already in use then if a new user tried to use that same email address they'd get a 409 since the email is unique.) (I omitted some status codes for brevity).
However since Portman sorts requests into "happy" and "unhappy" folders it would go: 1st folder of "happy" requests:
2nd folder of "unhappy" requests:
Yes, I could just add a second pet with the default values beforehand via a second pre-request script and the 409 would work as expected but just running the request before the original pet was deleted is easier/simpler. Another feature I would like to see if more support for generating "unhappy" requests via a "one size fits most" wildcard config that can match against the expected status codeCurrently we can match requests against the request type and route ( |
Thanks for the clear explanation and use-case description. We will need some time to investigate the ordering functionality. Just double-checking the 1ste case:
|
Hi. Sorry for the late reply, and thanks again for this great project! Yes, my main objective would be to facilitate having all POST opt be executed 1st. Based on current functionality, I would indeed expect matching against wildcards to be per folder. However, I'm personally fine with removing folders entirely because I can imagine some situations where people may want POST requests to go in a certain order that doesn't necessarily go in the same order a folder/tag would. Take this folder structure for example: Folder/tag 1:
Folder/tag 2
Say that a dog has to exist, a collar needs a dog, and the leash needs a collar. I can't run group two first because the dog doesn't exist yet. However, if I run the first group by folder it would try and post a leash second which would fail because the collars don't exist yet. So if there were no groups I could just order it Dog, Leash, Collar and not run into any issues. In hindsight the last part of my previous message really should have been its own dedicated feature request, but since I already put it there would you still like me to open an issue for "unhappy" requests via a "one size fits most" wildcard config that can match against the expected status code? |
@Fetchinator7 We implemented your suggested fix for supporting the wildcard in the orderOfOperations. It seems to cover the cases which could think off. We will include this in the next release of Portman. Currently we have kept support for orderOfOperations using the wildcard, where Portman is respecting the grouping per folder. So if you have Update: The wildcard support for orderOfOperations has landed in Portman version 1.13. 🙌 Thank you for contributing to Portman, since your example helped us to bring to fix. |
We have introduced this in release 1.10, with the option to define a "openApiResponse" for a variation.
You can review the example for some more details |
I struggle to fully understand the desired outcome. |
…deck-libraries#216) * Fix for order of operations, where the operations has multiple path variables (apideck-libraries#208) * Implemented suggested fix for orderOfOperations" with * wildcard (apideck-libraries#122)
Currently if I have an
orderOfOperations
config such as the one below in theglobals
it doesn't honor the order and uses the default sorting.This appears to be because orderCollectionRequests.ts currently only does a direct string comparison without accounting for a string that contains a
*
wildcard.I was able to get the above orderOfOperations config working by adding a RegExp (that escapes
/
) but this doesn't account for every input so a more complete solution would be in order.The text was updated successfully, but these errors were encountered: