You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unexpected behaviour of beforeEach outside of suite without test isolation #61854
In test runners such as jest or vitest, callbacks passed to the methods before, after, beforeEach or afterEach not wrapped in any describe, are called only when tests in their module are about to start or end. That's also the current behaviour when --test-isolation=process. Unfortunately, when the --test-isolation is none, the callbacks we pass to those 4 functions are added as global callbacks and they start to be called before/after each test in any file.
That's unexpected behaviour and it makes it more difficult to migrate from other test runners to node test runner or from the default --test-isolation=process.
What is the feature you are proposing to solve the problem?
Each module should be wrapped in a suite by default, so the callbacks don't leak to the other test modules. The only exception should be callbacks that we pass to those 4 methods in the global setup file(or its imports I guess).
I created a DRAFT PR for this that adds a "suite" automatically, but I am not sure is the correct approach, since it changes output structure. Probably a "filtering" hook" approach is the correct one.
Can we detail better which should be the expected behaviour, then @pmarchini ?
My 2 cents is that: if I specify a beforeEach hook in a module, it should be triggered only for that module, independently from --test-isolation.
Or -at least- this is what I expect (and it's coeherent with jest/vitest/etc behaviour).
Hey @marcopiraccini, following examples like MochaJS, when the test suite is run with isolation: none, all the root hooks from each individual test file are loaded before the run phase begins, since there is no process isolation in place.
In this scenario, all the “root-level” hooks end up being piled up.
I personally think this behavior is painful, since it introduces differences between isolation: none and isolation: process, but historically this is what we have in place.
This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
Activity
pmarchini commentedon Feb 16, 2026
+1 about this, I think we should avoid different behaviours between the
isolationoption!WDYT @nodejs/test_runner
marcopiraccini commentedon Apr 6, 2026
I created a DRAFT PR for this that adds a "suite" automatically, but I am not sure is the correct approach, since it changes output structure. Probably a "filtering" hook" approach is the correct one.
marcopiraccini commentedon Apr 7, 2026
Can we detail better which should be the expected behaviour, then @pmarchini ?
My 2 cents is that: if I specify a
beforeEachhook in a module, it should be triggered only for that module, independently from--test-isolation.Or -at least- this is what I expect (and it's coeherent with jest/vitest/etc behaviour).
pmarchini commentedon Apr 7, 2026
Hey @marcopiraccini, following examples like MochaJS, when the test suite is run with
isolation: none, all the root hooks from each individual test file are loaded before the run phase begins, since there is no process isolation in place.In this scenario, all the “root-level” hooks end up being piled up.
I personally think this behavior is painful, since it introduces differences between
isolation: noneandisolation: process, but historically this is what we have in place.marcopiraccini commentedon Apr 16, 2026
OK, clear. @pmarchini I am going to close my PR.
But if this is the expected behaviour we should close this issue too? Or is still under discussion?
github-actions commentedon Jul 27, 2026
This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
JakobJingleheimer commentedon Jul 29, 2026
We have an accepted proposal to add suite-level hooks, which then makes the happen-to-be global hooks more stark (that's then their only purpose).
I think that will address the unexpectedness of the describe behaviour? (which we agreed in today's meeting is indeed unexpected)