Context Injection Query For Async ReqNroll

[ChrisTyler-6788]

Hello,

Our team has begun the process of migrating from Specflow to ReqNRoll for our Playwright .NET/Nunit Test Framework, but in doing so we are experiencing issues due to the handling of threads in ReqNRoll. I am aware that ReqNRoll handles threads differently to that of Specflow, and wondered if we could get help in the best approach for obtaining our thread data in real time.

Our project implementation takes the following approach.

Feature File
-> Step File
-> Page Object Files
-> Components

In our Step File we reference our Page Object class which contains definitions for all our Individual components, these components are 'helper' classes which contain all the functionality we expect a given component to make and this is the point in which we use Playwright to interact with our components.

Our dilema here is we would like a way to initialise our WebDriver and PlayWright Page as part of the [BeforeScenario] event and then access this in our Component files without the need to inject this all the way through our step and Page Object definitions. Until now we have achieved this in Specflow using ThreadStatic variables which have been working correctly, but I believe this no longer works for ReqNRoll.

Is there a way to reference this data directly for inteligent extraction of this data?

Here is a highly simplified example of our approach to demonstrate the flow. Our tests are required to run in parallel and we have ~50+ components. Each page could have 20+ components defined, some of which are utilised multiple times.

Class Hooks

[BeforeScenario]

• Initialise Context class and set BrowserContext

Static Class Context

• Static variable 'BrowserContext' containing Playwright browser Context

Class Button
public async Task ClickButton(){
// use Context.BrowserContext to execute the action
}

Class MyPage
public Button saveButton = new("locatorID");

Class StepDefinition
MyPage page = new();

public async Task MyStepDefinition(){
page.saveButton.ClickButton();
}

Any advice or help with this approach would be greatly appreciated.

[Code-Grump]

As you have already surmised, the ideal solution here is to not couple your objects to threads or execution flows and instead lean on the DI system to provide these components to your other objects where they need them: it's precisely what the DI system is for.

You might be able to get something to work quickly by using AsyncLocal to flow values along the execution paths, but there are strict limitations to the direction of information flow and I cannot suggest it's a good long-term position for precisely the kind of problems you've encountered.

If there's something about using the DI system that's not working for you, or if you'd like to run through some examples of what you believe you'd need to implement, we can help validate the implementation and suggest potential improvements that might make it easier to swallow.

[gasparnagy]

Also please have a look at our sample app, you can get inspiration from that too. https://github.com/reqnroll/Sample-ReqOverflow/

[ChrisTyler-6788]

Thank you @Code-Grump, @gasparnagy for your help. We have taken a deeper look at the provided sample and how we can utilise this in our project, I see you have documentation for Service Collections, do you have any examples of how you would suggest to use this?

Ideally I want to minimise the complexity of our Test Step and Page object classes, with any dependency grabbing going directly into our Component layer which is managed by a central team as to aid our teams who have limited coding experience pickup test creation without the need to understand dependency injection and without the need for us to create Factory layers for our components which we do not need currently.

[gasparnagy]

We are currently about to redesign how the dependencies should be managed (see https://github.com/orgs/reqnroll/discussions/472) and our plan is to add end-to-end examples (in a form of a project template probably) that demonstrates the usage, but we don't have that yet.