Migration from Specflow - using undocumented feature

[orifn1]

Reqnroll Version

2.0

Which test runner are you using?

MSTest

Test Runner Version Number

3.2.2

.NET Implementation

.NET 8.0

Test Execution Method

Visual Studio Test Explorer

Content of reqnroll.json configuration file

It is not being used

Issue Description

In Specflow I could make such a call to receive injected context without using [Binding] attribute

TestRunnerManager
    .GetTestRunner()
    .ScenarioContext
    .ScenarioContainer

In Reqnroll I could use

TestRunnerManager
    .GetTestRunnerManager()
    .GetTestRunner(**workerId**)
    .ScenarioContext
    .ScenarioContainer

but ScenarioContext is always null and I do not know where I could take workerId for the current run
Is there any way to reuse Specflow approach

I need this in my custom IValueRetriever class

Steps to Reproduce

just run existing test

Link to Repro Project

No response

[gasparnagy]

Have you used that from a hook? If yes, which one?

[orifn1]

not just from ValueRetriever without any bindings or using from hook
I then just call
ScenarioContainer.Resolve<MyCustomObject>()

[gasparnagy]

For MsTest the short answer is that you can use System.Threading.Thread.CurrentThread.ManagedThreadId.ToString() as a worker id, but this is only true for MsTest and this API is going to change anyway soon (see #144).

The longer answer:

If you don't run your tests parallel, you can still use ScenarioContext.Current (despite the warning).

For parallel execution cases, it is not possible to guess in general that your ValueRetriever is called from the same thread as your scenario, so this is not generally possible. (Depends on the runner and if you use async or not.)

We plan to make an improvement on assist methods so that they are bound to the scenario context. See https://github.com/orgs/reqnroll/discussions/16.

What you can do as a temporary solution is to make a before scenario hook and save the scenario context to a thread local field until the mentioned feature will be ready. This will work in non-async parallel execution cases as well.

Does that help?

[orifn1]

Thanks, I will try it next week(if I will have enough time) and inform you

[gasparnagy]

I close this issue for now, but please feel free to reopen if there are any updates.

[orifn1]

I could not implement your suggestion quickly, so I decided not to spend time on it (because it is a temporary solution) and wait until the ticket https://github.com/orgs/reqnroll/discussions/16 is done.