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

Include Worker ID in env similar to Jest #270

Open
PaulMest opened this issue Nov 3, 2019 · 7 comments
Open

Include Worker ID in env similar to Jest #270

PaulMest opened this issue Nov 3, 2019 · 7 comments

Comments

@PaulMest
Copy link

PaulMest commented Nov 3, 2019

Is there any way to get the worker ID within the test or a test helper? The goal would be to use this to automatically set up a different port or database.

Jest offers this as process.env.JEST_WORKER_ID (jestjs/jest#2284, jestjs/jest#5494).

@nabilfreeman
Copy link

+1, so I can run 1 database per worker

@PaulMest
Copy link
Author

FWIW, I've migrated all of my projects to Jest and have been very happy.

@CoderSpinoza
Copy link

@PaulMest How long did it took for you to migrate? This feature is just essential for parallel tests...

@PaulMest
Copy link
Author

@CoderSpinoza
I think it all depends on how many tests you have to convert, how much can be done with a codemod, and if you have any other tools in your environment that don't support Jest.

For the most complicated project that involved dozens of tests and hundreds of assertions, it took a couple of days. Bulk of the work was done in ~4 hours.

Once we switched to Jest and larger test suites were running in under 30s, people started writing more tests because it wasn't seen as a pain.

@nabilfreeman
Copy link

nabilfreeman commented Jun 24, 2020

That's cool, I didn't think about using Jest on the back-end.

We actually wrote our own process management using child_process and inside the child files we passed in a database name and a test file to run. So now each suite runs in its own thread. The child process is running plain Mocha in require mode so this library wasn't necessary.

This actually had some neat advantages because the test suites were always running a fresh DB migration and completely separate, something we've had to be really careful about in teardown hooks in the past.

On the DB part itself I wrote a script that creates N databases in parallel (company-test-167) corresponding to each suite that will be run.

Finally some batch code using async-promise-pool that runs 3x the system cores in parallel (this was best setting for performance).

Really happy with the result but obviously highly custom. Our test times went down by 90% locally and like 99% on Codeship because you get a 128-core machine to run things on.

Same as Paul, our number of tests written has exploded since building this in March - the fast feedback loop is really critical for adoption IMO. We are also finally doing TDD because booting up the tests is finally fast.

@CoderSpinoza
Copy link

@nabilfreeman The result sounds great. Did you also have a chance to get aggregated coverage report from parallel tests?

@nabilfreeman
Copy link

nabilfreeman commented Jun 24, 2020

Great question @CoderSpinoza. I don't know how to do coverage in terms of nyc yet but we built our own coverage checker which counts:
% API routes tested
% ORM model helpers tested
% Utility methods tested

And returns an aggregate. Currently our coverage is still very bad and we're just focusing on getting API routes to 90%. 3 months work has taken us from <40% to 61%.

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

No branches or pull requests

4 participants