Skip to content
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

Closed
mjesun opened this issue Apr 11, 2018 · 15 comments · Fixed by #6006
Closed

#5585 breaks pre-established "beforeEach" order #5964

mjesun opened this issue Apr 11, 2018 · 15 comments · Fixed by #6006

Comments

@mjesun
Copy link
Contributor

mjesun commented Apr 11, 2018

When introduced #5885, the order of beforeEachs was inverted. Take the following test for instance:

describe('test', () => {
  beforeEach(() => {
    console.log('BeforeEach');
  });

  it('foo', () => {
    console.log('It Foo');

    beforeEach(() => {
      console.log('BeforeEach Inline Foo');
    });
  });

  it('bar', () => {
    console.log('It Bar');

    beforeEach(() => {
      console.log('BeforeEach Inline Bar');
    });
  });
});

The order should be:

BeforeEach
It Foo
BeforeEach Inline Foo
BeforeEach
It Bar

But it is instead:

BeforeEach
It Foo
BeforeEach
BeforeEach Inline Foo
It Bar

One might argue about beforeEachs inside its, 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.

@SimenB
Copy link
Member

SimenB commented Apr 11, 2018

Why should we support beforeEach inside of tests? Seems super wonky. Is this a case of "we're doing it in thousands of tests at FB, so can't change it"? If so, is it possible to set up a codemod fixing it? If anything, I'd expect it to break completely and not be supported. The fact ordering changed for something that's not documented shouldn't be cause for revert, IMO.

Also, where is BeforeEach Inline Bar? the whole thing seems buggy :P

/cc @niieani

@mjesun
Copy link
Contributor Author

mjesun commented Apr 11, 2018

Well, we've altered the process of adding on-the-fly beforeEachs into the queue. As explained, it is arguable that this is or isn't a desired thing, but it's currently supported and broken, so we should fix it.

BeforeEach Inline Bar does not appear because it would be a beforeEach executed after the following test case. Since bar is the last one, it will never get called.

@mjesun
Copy link
Contributor Author

mjesun commented Apr 11, 2018

On a side note, I published 23.0.0-alpha.5r, which is a clone of alpha.5, but with #5885 reverted, so that I could unblock myself internally.

@mjesun
Copy link
Contributor Author

mjesun commented Apr 11, 2018

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.

@niieani
Copy link
Contributor

niieani commented Apr 11, 2018

See my review that identifies the change here: #5885 (review)

Changing the order consistently would require moving line 64 between 59 and 60:

https://github.com/facebook/jest/blob/95f7813a8cc8f9988da2a9727bd7f8845348edfc/packages/jest-jasmine2/src/tree_processor.js#L59-L70

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.

@rickhanlonii
Copy link
Member

it's currently supported and broken, so we should fix it

@mjesun is it broken in the 22.x range or is it only in the 23 alpha?

@niieani
Copy link
Contributor

niieani commented Apr 11, 2018

@rickhanlonii this is in the latest alpha only.

@mjesun
Copy link
Contributor Author

mjesun commented Apr 11, 2018

I'm OK with moving the wrapChildren to the outer scope; I can also perform a quick test with your change internally and see if everything results in the expected behavior. 🙂

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.

No, you are right, whatever the behavior is, it should always be the same.

@mjesun
Copy link
Contributor Author

mjesun commented Apr 13, 2018

@niieani any updates regarding the change? We're going to release alpha.7 soon and it'd be nice to include that fix 🙂

@niieani
Copy link
Contributor

niieani commented Apr 13, 2018

Hey @mjesun, I think we misunderstood each other 😄

I was waiting for your quick test:

I can also perform a quick test with your change internally and see if everything results in the expected behavior

Did you try and see if that change works as intended?

@mjesun
Copy link
Contributor Author

mjesun commented Apr 13, 2018

Oh, I was waiting for the change 😅I need to merge and create alpha.7, then I can test it internally. I agree it was confusing 🙂

@mjesun
Copy link
Contributor Author

mjesun commented Apr 16, 2018

So... are you finally doing the fix? I need to revert if not :(

niieani added a commit to niieani/jest that referenced this issue Apr 16, 2018
…oring

fixes jestjs#5964
moves the `wrapChildren` into higher scope to restore undocumented execution order
@niieani
Copy link
Contributor

niieani commented Apr 16, 2018

@mjesun Oh man, I thought testing it internally meant you'll do it ;) So once again we misunderstood each other. Here's a PR: #6006

Looking forward to seeing it that fixes the issue.

@mjesun
Copy link
Contributor Author

mjesun commented Apr 17, 2018

Thanks for the fix! 🙂

cpojer pushed a commit that referenced this issue Apr 17, 2018
…6006)

fixes #5964
moves the `wrapChildren` into higher scope to restore undocumented execution order
niieani added a commit to niieani/jest that referenced this issue Apr 30, 2018
…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
niieani added a commit to niieani/jest that referenced this issue Apr 30, 2018
…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
niieani added a commit to niieani/jest that referenced this issue Apr 30, 2018
…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
@github-actions
Copy link

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.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants