Open chegancasb opened 7 months ago
@chegancasb , Have you looked at this(line no. 7) ?
"ignoreStep": true,
This seems might be helpful, but only partly to your usecase.
Because you needed this value config based, this doesn't seem like supports that. But anyway give it a run and try, if it doesn't solve, we will raise a ticket to sort this.
Hi @authorjapps,
Thanks for your reply. Your suggestion was actually my first attempt but the fact it was not modifiable through configuration, moved me away. I did not propose to extend the "ignoreStep" behaviour to allow it to interpret the input value but it might be a solution that would not add a new property. I anticipate that since it only accepts "true" and "false", the ability to resolve the provided dynamic value could be added without becoming a breaking change.
Regards,
On Tue, 23 Apr 2024 at 11:12, authorjapps @.***> wrote:
@chegancasb https://github.com/chegancasb , Have you looked at this https://github.com/authorjapps/zerocode/blob/master/core/src/test/resources/integration_test_files/failed_steps_with_ignore/01_two_step_one_fail_and_ignored.json#L7(line no. 7) ?
"ignoreStep": true,
This seems might be helpful, but only partly to your usecase.
Because you needed this value config based, this doesn't seem like supports that. But anyway give it a run and try, if it doesn't solve, we will raise a ticket to sort this.
— Reply to this email directly, view it on GitHub https://github.com/authorjapps/zerocode/issues/661#issuecomment-2071927577, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIGJ4IOYE7K7OWWERW676MTY6YXYRAVCNFSM6AAAAABGAIUU6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZRHEZDONJXG4 . You are receiving this because you were mentioned.Message ID: @.***>
In my team we use ZeroCode to support our component tests - where we validate the integration of our components against the services it interact with (some are real others mocks).
Given our use case, not knowing if more peoples have similar needs, I would propose the following.
We use the same scenario files in different use cases and some of those require specific actions to be done prior to each test. Currently we do have a way to incorporate this in scenario files because including those actions break some use cases.
The way I see this is to have additional step properties that determine if the step is or not evaluated. Something like:
where we implement a new optional parameter (
apply
in the example above) that by default is resolved toTRUE
but if defined its interpretation would determine if the step would actually be executed.In proposed example the step refers to a variable defined in the config_hosts.properties (
config.is_component_running_locally
) that would have to be interpreted to a bool value but it's execution could also be determined by a variable coming from previous steps.For simplicity sake I am proposing that the variable value would be restricted to directly boolean values convertible strings but a discussion on more complex expressions might be worth.
Thanks for your attention.