-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
support calling a scenario for data set up of dynamic scenario outlines #1905
Comments
+1 This is a great solution, thanks. |
@edwardsph @joelpramos just realized a complication. what if there is a Feature:
Background:
* print 'in background'
@setup
Scenario:
* def data = [{a: 1}, {a: 2}]
Scenario Outline:
* print __row
Examples:
| karate.setup().data |
thoughts ! |
cc @ericdriggs for thoughts since I remember you have a lot of complex "setup" flows |
another advantage of this system, it encourages re-use of data setup functions within any feature. so the very first example in this thread becomes: Feature:
@setup
Scenario:
* def data = [{a: 1}, {a: 2}]
Scenario:
* def temp = karate.setup().data
* match temp == [{a: 1}, {a: 2}] |
another reason why the another question can be should this support a EDIT see #2210 |
That all looks good to me. I wasn't sure about the problems with allowing a |
My first thought is the limitation of only one setup per feature. Can we change that by, for e.g., if there are multiple force a value name to the tag @setup=scenario1, @setup=scenario2 and throw an error if someone has multiple @setup in a feature or multiple setup with same matching value suggest the karate.setup() api to receive a string as a parameter and the default value is null (in addition to that second argument) For ‘callonce’ I think it should. One of the examples I have is the parameters of the test being keys/ids for a UI test but those keys/ids were pulled via an API call to a backend system as the system is a COTS product that auto generates those Background not running - not a problem. Was thinking here it could be inconvenient at times but there could be a @setup=background some can put in and not use in Examples tables but call directly from the other @setup Examples (assuming you’ll proceed with my suggestion). If it’s just one @setup Scenario a bit of Ctrl C + Ctrl V never hurt anyone |
@joelpramos okay, I'll try the |
Maybe I misunderstood the above. When you say support callonce mode is that it won’t support scenario outline dynamic (or however we want to call this now !) if the Feature is called from callonce or that the callonce keyword won’t be supported within the @setup method ? |
To check my own understanding, I think you were saying you will not add a flag to |
yes what @edwardsph said. to be honest troubleshooting propose I get the basic flow working, then consider which reminds me @joelpramos maybe we should release 1.3.0.RC1 without this big change, it may make it easier for you and others to validate the JS / multithread fix |
I’m aligned with the behaviour, it was my misunderstanding. Yes that would be great, Peter. |
remaining - include the extra scenario in reports documentation, and the support for multiple named setup scenarios in a feature
work in progress, pasting a particularly interesting example of before and after
part of the breaking change notes: earlier, all variables declared in the in other words, the |
multiple setup tags callable by name supported the setup scenario is also included in the feature report they even show up in the timeline report in the scenario-iterator thread only catch is if the setup runs more than once, it will be duplicated in the report which may be okay to figure how much overhead it adds
No strong opinion. Calling features from within outlines seems a nice to have. I don't grok why setup is needed in background nor why singleton nature is required. |
Looking good to me. Based on the description whatever is calculated out of the setup() will also be available on that background if it’s needed for some reason? I have no further suggestions I think might actually be needed. Above seems to serve the purpose you set out to solve. A suggest I have is to allow combinations of multiple examples tables in this fashion as well similar to “normal” examples tables (e.g. karate.setup(‘foo’, ‘bar’). Never had the need or use myself or used around as far as I’m aware but just a thought from a parity of capability with non-dynamic scenarios / example tables. Not sure complexity that might or might not introduce. |
@joelpramos no, the design is that a setup only returns data. once a outline "row" fires, the variables will be available as |
I don’t have a strong opinion for the need to have it available and like I said before, some copy pasting never hurt nobody if there’s really a need and there are multiple scenarios in the same Feature file. Might just need to be a detail mentioned in the docs. |
@joelpramos yes, I still need to write the docs for this and change existing docs. one thing I was able to validate, see screenshot below. so even in cases where we had a |
I'm interested in how this affects the reports. I currently generate a report for each test that includes the background and scenario steps. I suspect the setup steps will not be included since they are only used to generate the test. Is that correct? |
@edwardsph the good news is that the |
attention all - this change was merged to |
1.3.0 released |
@ptrthomas This is great. This adds to the readability and re-usability. |
attention all - decided to add an option to run the setup once, refer #2210 |
Hello @ptrthomas, Thanks for creating great tool. |
@dududadadodo please use stack overflow or follow this process: https://github.com/karatelabs/karate/wiki/How-to-Submit-an-Issue |
based on discussion in #1903
As of today this works:
what needs to work is this:
right now the
karate.call()
fails, there is some work to do in sequencing the call, making sure it runs at the time we init the feature etc. cc @edwardsph @joelpramosThe text was updated successfully, but these errors were encountered: