Update - looks like we solved this for the time being by removing our previous maxWorkers setting of 5 from our jest (test) config file.
According to the jest docs,
maxWorkers:Specifies the maximum number of workers the worker-pool will spawn for running tests. In single run mode, this defaults to the number of the cores available on your machine minus one for the main thread. In watch mode, this defaults to half of the available cores on your machine to ensure Jest is unobtrusive and does not grind your machine to a halt. It may be useful to adjust this in resource limited environments like CIs but the defaults should be adequate for most use-cases.
Note that you can specify the maxWorkers value in different ways:
- Number:
maxWorkers: 4(Use a maximum of 4 workers) - Percentage:
maxWorkers: "50%"(Use 50% of available CPU cores) - String:
maxWorkers: "2"(Same as using a number)
I’m thinking of trying out a percentage configuration to see what the sweet spot is for PocketIC on in different environments. We obviously want the tests to run as quickly as possible, so the maximum parallelization would be preferred, but we do need to create a new instance of pocketIC for each test file (suite) and then tear it down at the end to keep the test contexts separate.
@mraszyk do you have any suggestions/intuitions based on your in-depth knowledge of PocketIC
of the optimal parallelization setting that we might want to use?