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

Better test suite for binary tests #635

Merged
merged 23 commits into from Nov 4, 2018
Merged

Better test suite for binary tests #635

merged 23 commits into from Nov 4, 2018

Conversation

ematipico
Copy link
Contributor

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

@ematipico ematipico changed the title [WIP] Better test suite for binary tests Better test suite for binary tests Oct 10, 2018
@evenstensberg
Copy link
Member

Would be nice if we can remove async timeouts and try to make jest decide it

@ematipico
Copy link
Contributor Author

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?

Copy link

@SimenB SimenB left a 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.

See https://github.com/facebook/jest/blob/f00fbecb4b29b1f22582255d13591344a862b88e/e2e/runJest.js#L130-L150

(it should probably implement a Promise.race to send a kill before jest times out and give a good error)

const argsWithOutput = args.concat("--output-path", outputPath);

return new Promise(resolve => {
// try {
Copy link

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, [
Copy link

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

@ematipico
Copy link
Contributor Author

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?

@SimenB
Copy link

SimenB commented Oct 15, 2018

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 done callback argument when you return the promise. If your callback takes an argument, jest will wait for that argument to be invoked

@evenstensberg
Copy link
Member

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

@ematipico
Copy link
Contributor Author

ematipico commented Oct 18, 2018

@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.

@SimenB
Copy link

SimenB commented Oct 18, 2018

Oh btw, make sure to set maxWorkers on Travis of you haven't already. https://jestjs.io/docs/en/troubleshooting#tests-are-extremely-slow-on-docker-and-or-continuous-integration-ci-server

Running in band is overkill, I think there's 2 cores available on travis. You can run nproc

Copy link
Member

@evenstensberg evenstensberg left a 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",
Copy link
Member

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

* @returns {Object} The webpack output
*/
function run(testCase, args = []) {
// const cwd = path.resolve(testCase);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

?

@ematipico
Copy link
Contributor Author

ematipico commented Oct 20, 2018

What's missing is finding the right way to make the watch tests working on the CI.

@evenstensberg
Copy link
Member

@SimenB does this look ok?

@evenstensberg
Copy link
Member

Env variables for CIs needs to be adjusted but is there anything else?

Copy link

@SimenB SimenB left a 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());
Copy link

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);
Copy link

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
Copy link

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, [
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

async-await?

Copy link
Contributor Author

@ematipico ematipico Oct 30, 2018

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

Copy link

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 🙂

Copy link
Member

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?

Copy link

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

Copy link
Contributor Author

@ematipico ematipico Oct 31, 2018

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

Copy link
Member

@evenstensberg evenstensberg left a 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?

@evenstensberg
Copy link
Member

Does anyone know how we can avoid the jest timeout invocation in Travis and Azure?

@SimenB
Copy link

SimenB commented Nov 3, 2018

Increase the timeout? CI is generally really slow unless you pay money for more cpu/ram

@evenstensberg
Copy link
Member

There we go. Could you elaborate on extractSummary?

@ematipico
Copy link
Contributor Author

We can have that extractSummary utility later. I'd like to get this done. We should increase the timeout to 60 seconds as before

@SimenB
Copy link

SimenB commented Nov 3, 2018

extractSummary in Jest is just a function that splits out the summary from everything else in stdout, allowing you to make more granular assertions about the output that's unique to a test. Mostly cosmetics, so no need to wait for it to merge this PR 🙂

@evenstensberg
Copy link
Member

I think that would be nice. Let's wait for azure to update its env vars and then add a issue on it! :)

@webpack-bot
Copy link

Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon.

@ematipico ematipico merged commit 8f68555 into webpack:master Nov 4, 2018
@SimenB
Copy link

SimenB commented Nov 4, 2018

🎉

dhruvdutt pushed a commit that referenced this pull request Nov 4, 2018
* 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
Copy link
Member

@dhruvdutt dhruvdutt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merged as ca1e4a3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants