Jest: Feature Request: Add --runInBand to package.json options

[JamesMcGuigan]

This is a feature request.

I currently have a setup that involves jest tests asyncronously creating and re-aliasing elasticsearch indices and part of their setup and tear down routines.

The tests run perfectly fine if I specify jest --runInBand on the command line.

If I run them without --runInBand I get random test failures due to the inherent race conditions with running these tests asynchronously.

What I would like is an option in package.json:

{
  "jest": {
    "runInBand": true
  }
}

Such that the flag is automatically applied to jest (like all the other package.json settings), without needing to manually specify it on the command line each time.

The lack of this feature may potentially confuse other developers on my team who attempt to run the jest tests without being explicitly aware the tests are dependent on the --runInBand flag being present, thus observing a broken test suite.

package.json is the correct place to document this configuration dependancy

Thank you.

[cpojer]

I'd prefer not to do this. -i is an escape hatch. It would be better to find a way to run the tests in parallel.

---

From: James McGuigan [e-mail]
Sent: Tuesday, March 28, 2017 6:24:32 AM
To: facebook/jest
Cc: Subscribed
Subject: [facebook/jest] Feature Request: Add --runInBand to package.json options (#3215)

This is a feature request.

I currently have a setup that involves jest tests asyncronously creating and re-aliasing elasticsearch indices and part of their setup and tear down routines.

The tests run perfectly fine if I specify jest --runInBand on the command line.

If I run them without --runInBand I get random test failures due to the inherent race conditions with running these tests asynchronously.

What I would like is an option in package.json:

{
"jest": {
"runInBand": true
}
}

Such that the flag is automatically applied to jest (like all the other package.json settings), without needing to manually specify it on the command line each time.

The lack of this feature may potentially confuse other developers on my team who attempt to run the jest tests without being explicitly aware the tests are dependent on the --runInBand flag being present, thus observing a broken test suite.

package.json is the correct place to document this configuration dependancy

Thank you.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/facebook/jest/issues/3215, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAA0KI5INcWs1BFGWPxPeoYDHKjg1uQrks5rqCkQgaJpZM4Mq2Fy.

[thymikee]

Create a npm script and don't think about it?

"test:es": "jest -i"

[jdxcode]

Just want to give my 2 cents on this one. We use jest for lots of integration tests in a project and set -i like above which works, but it's a bit annoying when you want to run jest --watch or any other one-off jest command. We've looked into parallelizing this suite, but it's very tough to do for us given the nature of the project. Most of our projects work fine parallelized, but this one is full of integration tests that install/uninstall plugins to a CLI that requires a lock over the system.

Yes we could maybe sandbox it out so it would run, but really, we'd rather just run the tests in serial and be done with it. I think it's a great idea to encourage developers to write tests such that they won't collide with one another, but it shouldn't be annoying to run jest without it.

Anyways, this is one man's opinion.

[thymikee]

@dickeyxxx you can put your configuration into a JS file and set process.env.CI=true since Jest 20, maybe that helps?

[jdxcode]

seems it still does the same thing: https://github.com/heroku/cli-engine/commit/310aa52ee810c7014a2d9cba82b7fb5ea85c8a94

$ jest --version
v20.0.0
$ jest
● Validation Warning:

  Unknown option "runInBand" with value true was found.
  This is probably a typing mistake. Fixing it will remove this message.

  Configuration Documentation:
  https://facebook.github.io/jest/docs/configuration.html


 RUNS  src/integration.test.js
 RUNS  src/namespaces.test.js
 RUNS  src/plugins/user.test.js

Test Suites: 0 of 16 total
Tests:       0 total
Snapshots:   0 total
Time:        0s, estimated 47s

[lgandecki]

This would be very useful for jest projects as well (if I have a runner for a e2e tests + unit tests, I want to be able to run e2e inBand, and unitTests in parallel, right now my only option to run all of them one or the other way)

[b4dnewz]

Hi, I know this issue is closed but there is a particular reason why the command options you can pass are different from the configuration options?

I mean, we can always use like this: jest --runInBand as thymikee said but let assume someone have this setup:

"scripts": {
    "test": "jest --runInBand"
 },
 "jest": {
    "bail": true,
    "verbose": true
 }

Compared to this:

 "jest": {
    "bail": true,
    "verbose": true,
    "runInBand": true
 }

It's more readable and manageable all in one place, this example is simple but can be more complex in certain projects.

[mgcrea]

Also another valid use case is when you are in a monorepo configuration and running jest globally with a projects config:

If one of your packages has to run serially, the only option is to run everything serially with --runInBand with a very poor performance. Would be great if each project could define if they have be run serially or not.

In an extreme case, even if all your packages must run serially, jest should still be able to run each projects in parallel.

[Adverbly]

The detectOpenHandles flag used by the cli is another example of a flag missing from config. Would indeed be very nice if all flags could be made config.

[SimenB]

In the case of detectOpenHandles it has an unfortunate performance overhead, so you don't really want it all the time.

It's designed to be used when needed, not all the time, so adding it as config doesn't really make sense.

---

As an aside, runners can say that they have to run serially, if that helps

[lukepighetti]

As an aside, runners can say that they have to run serially, if that helps

@SimenB how?

[SimenB]

See #5712

[capaj]

please consider reopening. Even though it has forced me to improve our test pipeline significantly(instead of passing runInBand everywhere I made sure we run each worker against his own DB), it would be very nice to have for projects which really need a serial test runner.

[AntonNarkevich]

If there is a CLI option there should be a config file equivalent.
The API is inconsistent otherwise.
Also forcing users to run tests in parallel is not a good thing. If you wanna flag that parallel execution is beneficial why not simply add an execution time hint?

[ranyitz]

@capaj & @AntonNarkevich As pointed out it's currently possible to configure a runner to run serially.

Here is a simple example:

extend the default jest-runner and only change its isSerial property.

// serial-jest-runner.js
const DefaultJestRunner = require('jest-runner');

class SerialJestRunner extends DefaultJestRunner {
  constructor(...args) {
    super(...args);
    this.isSerial = true;
  }
}

module.exports = SerialJestRunner;

// jest.config.js
{
  runner: './serial-jest-runner.js',
}

[olivierlacan]

So in order to configure Jest to do something it can do with a flag, you need to create a custom runner whose sole purpose at 11 lines of code is to do something a configuration like could do in 1 line? That's a bit much.

isSerial: true

I'd recommend avoiding spiraling config value synonyms. runInBand is fairly self-explanatory (and suggests its relationship with the runner) and implies a truthy default so --runInBand and runInBand: true should be equivalent. runInBand: false would be identical to omitting --runInBand as a flag. Unless isSerial has some semantic reason to exist which I'm missing, it should be deprecated and its value assigned to runInBand if that's not already the case.

[danielzgtg]

This seems to be available now but undocumented as { "maxWorkers": 1 }.

[trulyronak]

@danielzgtg seems like its gone - it really makes 0 sense at all why they wouldn't surface a cli feature in the config, when there's a clear reason to want to run certain tests in sequential order. Not everything is going to be parallelized, this is ridiculous.

[godrose]

Why is this closed? It's a valid request that's been ignored for several years.