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
Better test suite for binary tests #635
Conversation
Would be nice if we can remove async timeouts and try to make jest decide it |
That's the thing. In these tests we are running the watcher and I followed the same pattern of before, where we kill the process after a while, collect the result and after that we run the assertions. Do you have a better solution? |
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.
Awesome that you picked it up! Feel free to ping me with questions 🙂
Do you have a better solution?
Not sure if relevant or not, but in Jest we have some tests that are supposed to hang (e.g. e2e test for a server hanging forever). In that case we wait for some output to appear in stderr, and when it does, we kill the process. This allows us to wait only as long as we have to, meaning we don't waste time.
(it should probably implement a Promise.race
to send a kill before jest times out and give a good error)
test/testUtils.js
Outdated
const argsWithOutput = args.concat("--output-path", outputPath); | ||
|
||
return new Promise(resolve => { | ||
// try { |
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.
You can do Promise.resolve().then(() => execa(...))....
to avoid doing new Promise
. Not sure if it's better or not
jest.setTimeout(10000); | ||
|
||
test("single-config", done => { | ||
runWatch(__dirname, [ |
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.
you can return the promise instead of using done
, then jest will wait for it
Hi @SimenB , thanks for your feedback!! Really appreciated! I tried to follow your suggestions but still we got issue inside the CI. Probably there's something that I am still missing... So, I kill the process when there's some output (like you suggested where you wait for some kind of error). When there's output, we kill the process. Inside jests tests, I return the promise and in theory jest should wait for it. Although on Travis it keeps failing with a timeout error, so Jest it's not waiting properly... any tips? |
Jest has a timeout of 5 seconds. If your test takes longer than that, you have to increase the timeout. Also note that you have to remove the |
What Simen proposed was something I was looking for. As we don't need to wait in a fixed interval for each compilation to finish. An ETA of each compilation would be < 15s and I think 60 as a fixed limit for any compilation would be useless when we can await for output. What would be ideal is not to spawn processes in sequence, but in parallel, as each test is isolated |
@ev1stensberg Yes it would be super awesome, but on Travis it looks like that the process takes A LOT to print out some output and because of that the test fails :( I tried now to increase the jest timeout to 30 seconds and see how it goes. |
Oh btw, make sure to set Running in band is overkill, I think there's 2 cores available on travis. You can run |
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’s missing at this PR?
package.json
Outdated
"webpack-dev-server": "^3.1.8" | ||
} | ||
"name": "webpack-cli", | ||
"version": "3.1.2", |
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 you avoid rewriting the entire package? Hard to review
test/testUtils.js
Outdated
* @returns {Object} The webpack output | ||
*/ | ||
function run(testCase, args = []) { | ||
// const cwd = path.resolve(testCase); |
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's missing is finding the right way to make the watch tests working on the CI. |
@SimenB does this look ok? |
Env variables for CIs needs to be adjusted but is there anything else? |
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.
Looks great!
You might consider running execa async instead of sync, but check the run time first.
]); | ||
|
||
expect(code).toBe(0); | ||
expect(stdout).toEqual(expect.anything()); |
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.
Unnecessary assertion
expect(stdout).toEqual(expect.anything()); | ||
expect(stdout).toContain("./index2.js"); | ||
expect(stdout).toContain("./index3.js"); | ||
expect(stderr).toHaveLength(0); |
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.
toBe('')
? Or toEqual
[0] ./index.js 265 bytes {0} [built] | ||
[1] ./ok.js 23 bytes {0} [built] | ||
|
||
WARNING in configuration |
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.
In Jest we have a helper called extractSummary
which might be nice here. Separates summary
from rest
const { runWatch } = require("../../../testUtils"); | ||
|
||
test("info-verbosity-off", () => { | ||
return runWatch(__dirname, [ |
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.
async-await?
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.
We still support node 6 and we don't use Babel. I would have used it already if I could
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.
Jest comes with babel support out of the box (that's how code coverage works), so you can just add babel-preset-env
and use it in tests if you want, even if you don't want to transpile your source code. Up to you, though 🙂
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.
Preset env is doable, but will it throw on node v6 and below?
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.
nah, just use node: 'current'
as target
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 wouldn't mind to use babel for your test suite honestly 😄 It would make everything easier to write
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.
Lgtm here, removed the empty string checks @ematipico . Does this look good @SimenB ? CC @TheLarkInn can you update nproc = 4
to a env variable in Azure?
Does anyone know how we can avoid the jest timeout invocation in Travis and Azure? |
Increase the timeout? CI is generally really slow unless you pay money for more cpu/ram |
There we go. Could you elaborate on |
We can have that extractSummary utility later. I'd like to get this done. We should increase the timeout to 60 seconds as before |
|
I think that would be nice. Let's wait for azure to update its env vars and then add a issue on it! :) |
Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon. |
🎉 |
* chore(tests): PoC on new way of running integration tests * tests(refactor): started moving to a better test suite case * tests(refactoring): refactored entry point tests * tests(refactoring): refactored entry points tests * tests(refactoring): refactored configFile bins * tests(refactoring): refactored errors * tests(refactoring): ported the rest of the tests * chore(tests): remove snapshots that are dynamic * chore(tests): moved setTimout before running the tests * chore(tests): applied suggestions on async tests * chore(tests): apply timeout to wait for output from the process * chore(tests): added maxWorkers to CI * chore: revise n-workers * chore: update tests * chore: add async-await and revise babel * chore: increase timeout * chore: revise timeout * chore: more async timeouts * chore: add async timeout * chore: async
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.
Merged as ca1e4a3.
What kind of change does this PR introduce?
Refactor of the test bin cases in order to run them singularly. Also, it implements snapshot tests
Did you add tests for your changes?
Well, kinda :)
If relevant, did you update the documentation?
Not yet, probably I will once everything is ready
Summary
So, taken from #621 I started the refactor of the bin tests.
As suggested, I removed from the stream of the output everything that has the Hash, timestamps and versions. This is because they change at every build/version change of webpack, causing the fail of the snapshot test.
Also, as suggested, we could change the way we pass the arguments from being an array to being an object. Feedbacks are welcom
Does this PR introduce a breaking change?
Other information
Let's have some feedback