Closed deyanp closed 5 months ago
You are doing it correctly considering what is available. We are currently not providing any mechanism to provide scenario information to step implementations.
If we want to add native support to tickspec, I believe that the cleanest way (that is independent on the test runner) would be to use the underlying service provider - at the beginning of every invoke when we instantiate the service provider, we can register an instance of some "scenario information". That would allow any step to have extra argument with the right type and that would be filled with the current scenario information.
If you want to take a look, then look how the scenarios work in the following example: https://github.com/fsprojects/TickSpec/tree/master/Examples/ByFeature/FunctionalInjection
The instantiation of service container is in the following places:
The ScenarioGen
is the reason we keep support for the .NET Framework. We have not implemented an alternative for .NET Core that would have the same functionality (breakpoints to feature files). We should either look at how to do it in new .NET or drop the support completely. I can imagine that the learning curve for the emit is not contribution-friendly and the benefit of supporting old .NET fw.
Opened a pull request with support for it: https://github.com/fsprojects/TickSpec/pull/61
Imagine I have some tag on a scenario-level:
How can I get to the tags collection from within a step like:
I have implemented (similar to what I explained in https://github.com/fsprojects/TickSpec/issues/46) a static dictionary in which (based on ManagedThreadId) I inject the tags in the Theory/MemberData decorated stub function, and get them later on from the step implementation, however I am sure @mchaloupka will have a better idea ...
I also looked at https://github.com/fsprojects/TickSpec/tree/master/Examples/ByFeature/TaggedExamples but could not understand it ..