-
-
Notifications
You must be signed in to change notification settings - Fork 964
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
Proposal: Bruno Workflows #71
Comments
Hey @ajaishankar ! This is a really awesome proposal 👏👏. Very well written and really some very innovative ideas here (specially around param passing) I feel we should discuss and ideate on this more before we get into implementation. Here are my comments. Parameter passing across requests Workflows as first class citizen (FCC) Workflows as subroutines inside tests Ex: Let's say your app is JIRA, and you wanted to write 10 tests. Typically in postman you would create 10 folders, and write steps inside them. Each test/folder had many steps that were common across them. You could actually group these common steps as "workflows" and have tests call them (kind of like a subroutine). Is "collection" even the right abstraction ? Scripting Moving forward I feel we can implement your idea of updating variables based on response that can be subsequently used when running the next request. This feature seems fundamental. I have some thoughts on how this could be done with scripting. Will write it in detail tomorrow. Again, fantastic proposal @ajaishankar . Made me think deeply. Let me know your thoughts. Feel free to voice disagreements and point out flaws in the line of thinking here. |
Thanks @helloanoop On collections vs workflows - saw this in the postman documentation. https://learning.postman.com/docs/running-collections/building-workflows/ But the above looks like an afterthought. Whether we really need workflow as a FCC is debatable. But the distinction between a collection vs workflow is simply the fact that you cannot run an arbitrary step in a workflow whereas in a collection you can. On scripting, I'd keep that as an option (for sure) for advanced users but the primary focus should be declarative imo. If you see the Postman link above, outright they are looping and branching which is I feel is bad. On tests the primary use case could be "black box testing" - run a workflow and verify the final json response matches what we expect. Again we can pick and choose the values to assert using json-query.
{
"$res.data.user.name": "bruno"
}
{
"$res.status": 401
} Throw in some query helpers similar to jest asserts (see isDefined below) and and you are well on the way to a nice zero code experience!
{
"$res.data.order.items.length": 2,
"$res.data.orderNumber:isDefined": true
} And if you really need complex logic when the final assertion is evaluated, we can pass say lodash to the context. {
"_.filter($res.data.pets, p => p.name === 'bruno').length": 1
} |
Love the long term vision of having a .bruno folder in the source code! The UI looks good, but just one question: Would it make sense to have the Assert configuration only in the right hand pane?
|
Would it make sense to have the Assert configuration only in the right hand pane? Also we can show the actual values side by side in that Assert tab itself... @ajaishankar it'd be great if you want to take a stab at implementing this, I feel we are both aligned here on the assertions part. I was thinking we will use the request tab to code the assertions, and the response tab to show the assertion results (kind of like of how postman allows to write scripts in request pane, and displays test results in response pane). |
Got it! Yes I'll take a stab at implementing this... 👍 |
@helloanoop put more thought into workflows and looks like we need not make it into a FCC! Turns out the current abstraction of collections and requests will suffice. Here is a reference workflow implementation using collection variables. Demo The data picked up from the the response of the first request becomes input for another request in the collection. The difference from Postman is the data dependencies are declaratively specified and easy to reason about. https://github.com/ajaishankar/bruno-vars Let me know what you think... |
@ajaishankar Slick demo! Appreciate the time you put in to create the demo. Onboard with the approach of declaratively specifying the data dependencies in vars. Currently bruno has env variables (similar to postmans env variables concept). |
Thanks @helloanoop Yes your visualization is correct 👍 vars are declared in the request pane as in your screenshot (which btw looks far better than my horrible attempt at UI 😃) Just to summarize:
This is the Postman collection var docs. https://learning.postman.com/docs/sending-requests/variables/ Where I feel our approach shines is everything being declarative, and being able to track inter request dependencies. For example some var set in request one is used in request five... |
Hey @ajaishankar Had taken some time off from the project. I am back again at it. I think we are at a good place to get start implementation on this.
Another important thing to note is that currently, there is no concept of a session in bruno, and currently ordering/sorting requests within the collections is not possible. I am currently working on it. This should be ready in a week's time. What I am to get done is to initially support ordering requests based on drag-n-drop and then support option to run a collection / folder within the collection. |
Sorry for late response... on question 2 on how we know if a var is a response var? Postman has a list of dynamic vars, and for us similarly Any expression that refers to |
@ajaishankar Have added a new ticket to track how proposals would work as per the latest bru lang spec #87 |
This is a proposal for implementing workflows in Bruno.
Somewhat related to Bruno Test Script RFC #46
Workflows:
Examples:
A workflow would be a first class concept in Bruno similar to collections.
Defining a workflow is simple enough, but how do we pass variables over is the interesting part of this proposal.
In Postman after an API call we can run a "post request script" to set collection variables, which are then reused in rest of API calls. But usually it is difficult to understand what the script does, what variables are set, since these are well... scripts :)
Workflow implementation
The idea is... look ma, no scripts!
Update profile workflow steps
post script config
Tests:
Everything being simple json provides a lot of benefits and opportunities.
@helloanoop I can do a PR if this is something you'd be interested in.
The text was updated successfully, but these errors were encountered: