[Question] Scoped test suite contexts

I need to test a pretty typical password-reset page. The page is only available after going through a relatively long flow: Go to sign-in page, click password reset link, enter email, click submit, open email, click link in email, arrive on tested page.

Multiple elements must be tested on this page: do a visual regression test, make sure the right error helpers appear, etc. Each element needs its own test().

Multiple “suites” of tests need to be executed, some of which end by actually performing the password reset, which invalidates the page’s URL and makes it unavailable to further testing.

Here are the options considered so far:

• Using a non-scoped fixture, the initial flow would be repeated for each individual test, which is not efficient and would blow up testing time.
• Using a worker-scoped fixture, the initial flow is only done once, but can’t be redone if the reset page is invalidated. Any test that runs after a password reset is performed will fail.
• Using a single test() with nested test.step()s works, but makes it impossible to selectively run specific steps (for instance using the VSCode extension).
• Using test.beforeAll() to set up the flow requires a common page object to be provided by a worker-scoped fixture, so that it can be used by subsequent test()s. This solution doesn’t guarantee that the provided page is isolated and in a usable state. As it is shared across all tests, some might use it to sign in, then the password reset page would be unavailable. Relying on this sort of global, shared object will undoubtedly lead to test flakiness.

Is there anything obvious I’m missing? Having the ability to generate private, scoped, disposable contexts that can be used across a defined set of tests would be very helpful.

[yury-s]

We don’t have plans to implement suite-scoped fixtures but let’s keep the issue open for some time to see if it gets enough upvotes.

[idmadj]

At this point I’m fairly confident that you pointed me towards the most optimal solution using the current capabilities.

You can prepare the page in beforeEach instead

This is not possible as the page needs to be prepared before the code in beforeAll (the logic in beforeAll depends on the page as prepared by the overriden fixture).

You don’t have to use built-in page fixture and can reference passwordResetPage variable directly.

I actually do want to use the logic from an overridden page fixture in beforeAll. From what I understand, I would need to repeat any code that’s in that fixture override into the beforeAll body to achieve that goal, which I’d rather avoid.

I believe you can turn passwordResetPage/‘signInPage’ in a worker fixture, something along these lines … Bear in mind though that such fixture are torn down only after all tests in the worker.

That wouldn’t work as each test would perform some navigation on the used page, meaning that subsequent tests wouldn’t necessarily begin from the same state.

This is another reason why I think the addition of group-scoped fixtures would be of great help. Generally, using beforeAll along with fixtures makes it hard to encapsulate and reuse code across a project as they ultimately use different paradigms despite serving similar purposes.

Let’s close this issue at this point as I think we’ve got to the bottom of the problem. I’d just like to add my voice to those who believe that group-scoped fixtures would bring significant benefit to the elaboration of more complex tests. Let me know if I should open a separate feature request issue.

Thanks a lot for your help and support.