@rosshadden What do you think?

I ran it locally on OS X and my stats were:

Test Suites: 40 passed, 40 total
Tests:       118 passed, 118 total
Snapshots:   7 passed, 7 total
Time:        308.429s

But it's much faster in CI. How about your machine?

@rosshadden What do you think?

I ran it locally on OS X and my stats were:

Test Suites: 40 passed, 40 total
Tests:       118 passed, 118 total
Snapshots:   7 passed, 7 total
Time:        308.429s

But it's much faster in CI. How about your machine?

@machikoyasuda one of the main reasons this happens is due to the specification of the host CPU of the docker container. For eg, you would be running the tests on macbook pro which may have an i5 or i7 mobile processor while the CI instance has a XEON server processor, which has a massive difference in single core performance. This is important as we are using --runInBand which uses a single core of the CPU.

Test results on my machine take:

Test Suites: 40 passed, 40 total
Tests:       118 passed, 118 total
Snapshots:   7 passed, 7 total
Time:        255.031s

My laptop has the intel i7 9750H mobile processor.

@rosshadden with --maxWorkers the tests take more time to complete and even cross the 5000 ms default jest timeout causing tests to fail locally. To not let this happen most of the tests have jest.setTimeout(30000) but there are some tests that don't have this setting. If you could share the error information of the tests failing while using --runInBand.

I've been out, but to add a little context:

The --runInBand is necessary to get the full benefits of the @shelf/jest-mongodb package. It creates the MongoDB server in Jest setup code and destroys it in Jest teardown code. If you run tests in parallel, then it will do this in every process and tests will be much slower.

I'm not sure if any automatic data destruction happens between tests. I don't think any tests are creating many documents without removing them after, but that could be one thing to check, especially if it keeps some of the mongo data in memory.

So this PR looks fine to me

FYI @spencern