-
-
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
Add Global Setup/Teardown APIs #4716
Conversation
ca2c222
to
ea82f18
Compare
docs/Configuration.md
Outdated
### `globalSetup` [string] | ||
Default: `undefined` | ||
|
||
This option allows the use of a custom global setup module which exports an async function. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does "global setup" mean? (I know, but I want the docs to clearly state what the purpose of the option is)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure the tests prove anything beyond the what setup and teardown does for test environments. I'd add more test files and have a test asserting that whatever sideeffect the setup does is only done once.
Also please update the changelog
c12bad7
to
2253417
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a small suggestion for assertion, but overall this looks great! Really looking forward to seeing what we can do with puppeteer once it's properly supported in Jest. Thanks for all your help!
|
||
test('should exist setup file', () => { | ||
const files = fs.readdirSync(DIR); | ||
expect(files.length).toBe(1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
toHaveLength
(can be used multiple places)
const fs = require('fs'); | ||
const os = require('os'); | ||
|
||
const DIR = os.tmpdir() + '/jest'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we replace all these concats with path.join
/path.resolve
?
2253417
to
d42f293
Compare
Will this run once per worker, or per jest process? |
It will run once per jest instance. |
Should we make it run once upon all jest instance? |
I'm not sure what makes most sense. I'm inclined to keeping it once per jest process and not per worker. @cpojer? |
I'm not particularly happy about this. What problem is this feature solving? The way this works right now is that it runs before any tests and after any tests, but it in the parent context and not in the context of tests. Running it once per worker makes little sense, because that is for a set of 0–N tests and it's not deterministic (workers could crash and be restarted etc.). Making it once per test seems unnecessary also, because we now have async hooks for custom test environments. |
@cpojer This PR could solve my issue. Currently, I am testing an app that consumes a port. When Jest concurrently runs tests, all my suites attempt to consume the same port. I have to pass in the The global setup and teardown will ensure only one server will spawn to consume a port, and all tests will test off that same server. |
I'm not sure why someone is not particularly happy about this PR when problems like this will be solved by this PR. |
const DIR = path.join(os.tmpdir(), '/jest'); | ||
|
||
module.exports = function() { | ||
return new Promise((resolve, reject) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xfumihiro Everything inside this function in synchronous. So do we really need to wrap this in a promise?
the same applies to tread-down also.
I think this is causing the test to fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests only failed on windows(appveyor) so that can't be the case.
Otherwise all tests should failed also.
However, until the team approves this PR, there's no point spending more time on it.
@SimenB mind resolving the conflict? Happy to merge after all the people are supportive. |
@xfumihiro can you rebase and fix the test on appveyor? |
@SimenB Sure! |
d42f293
to
5b75b69
Compare
a971c18
to
0fbc771
Compare
0fbc771
to
fc15a72
Compare
Codecov Report
@@ Coverage Diff @@
## master #4716 +/- ##
==========================================
- Coverage 60.76% 60.75% -0.01%
==========================================
Files 198 198
Lines 6603 6607 +4
Branches 4 4
==========================================
+ Hits 4012 4014 +2
- Misses 2591 2593 +2
Continue to review full report at Codecov.
|
Let's do it! Thanks everyone for chiming in. |
An example in the docs for usage with puppeteer would be awesome! winkwinknudgenudge |
@cpojer could you publish the beta so I can write an example for this. 😃 |
@xfumihiro a beta has been published. Also, see https://medium.com/@jsilvax/getting-started-with-jest-and-puppeteer-7cf6c59a2cae |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
Adding Global Setup/Teardown APIs
Test plan
jest.config.js
setup/teardown.js