-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#5585 breaks pre-established "beforeEach" order #5964
Comments
Why should we support Also, where is /cc @niieani |
Well, we've altered the process of adding on-the-fly
|
On a side note, I published |
On another side note: this happens with inlined requires; I just oversimplified the code to give a simple test case; but real-life scenarios are way more complex than this. |
See my review that identifies the change here: #5885 (review) Changing the order consistently would require moving line We could also parametrize it for the top-suite case so its evaluated early, but I don't think keeping inconsistent behavior is the way to go. Please advise on how to continue. |
@mjesun is it broken in the 22.x range or is it only in the 23 alpha? |
@rickhanlonii this is in the latest alpha only. |
I'm OK with moving the
No, you are right, whatever the behavior is, it should always be the same. |
@niieani any updates regarding the change? We're going to release |
Hey @mjesun, I think we misunderstood each other 😄 I was waiting for your quick test:
Did you try and see if that change works as intended? |
Oh, I was waiting for the change 😅I need to merge and create |
So... are you finally doing the fix? I need to revert if not :( |
…oring fixes jestjs#5964 moves the `wrapChildren` into higher scope to restore undocumented execution order
Thanks for the fix! 🙂 |
…documented execution order We do not set the currentDeclarationSuite upon node start in order to keep a legacy, undocumented ordering of beforeEach execution. Specifically, this applies to beforeEach that were added inside of tests. Facebook depends on this behavior internally (see jestjs#5964 for discussion) Also: Added type of CreateOptions in jasmine_light
…documented execution order We do not set the currentDeclarationSuite upon node start in order to keep a legacy, undocumented ordering of beforeEach execution. Specifically, this applies to beforeEach that were added inside of tests. Facebook depends on this behavior internally (see jestjs#5964 for discussion) Also: Added type of CreateOptions in jasmine_light Added legacyExecutionOrder: false to DEFAULT_PROJECT_CONFIG
…documented execution order We do not set the currentDeclarationSuite upon node start in order to keep a legacy, undocumented ordering of beforeEach execution. Specifically, this applies to beforeEach that were added inside of tests. Facebook depends on this behavior internally (see jestjs#5964 for discussion) Also: Added type of CreateOptions in jasmine_light Added legacyExecutionOrder: false to DEFAULT_PROJECT_CONFIG Updated test snapshots
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
When introduced #5885, the order of
beforeEach
s was inverted. Take the following test for instance:The order should be:
But it is instead:
One might argue about
beforeEach
s insideit
s, but the reality is that this is supported and the current order is altered. We need to get some sort of fix or rather revert the PR.The text was updated successfully, but these errors were encountered: