Skip to content

Conversation

@ojongerius
Copy link

Seeing you run jest --runInBand would have saved me some time figuring out why this did not work in my repo 😄

It might actually be worth elaborating on passing runInband, as running serially won't be great for performance.

Seeing you run `jest --runInBand` would have saved me some time figuring out why this did not work in my repo.

It might actually be worth elaborating on passing `runInband`, as running serially won't be great for performance.
@vladholubiev
Copy link
Member

@ojongerius hey, thanks for the clarification!

I used --runInBand before as well, but it is not needed if you close connection properly.

See this comment from Jest team:

jestjs/jest#5571 (comment)

And a small fix which eliminated this anti-pattern: jestjs/jest@513a6fb

So what do you think if instead of mentioning --runInBand, you'd mention how to not forget to close connections?

@ojongerius
Copy link
Author

@vladgolubev that's a good point, thanks for that suggestion. I'm running mongoose and if I add a mongoose.disconnect() in the afterAll my tests work and teardown is fast too 🎉

@ojongerius
Copy link
Author

So AFAIC as described in #3 running with --runInBand is non optional. It could do with some explanation but as I'm not sure why this is happening I have no idea what I'd write there 😆

Any suggestions?

@vladholubiev
Copy link
Member

@ojongerius as I replied in #3, I tested it on my repo with ~400 tests and it works without --runInBand flawlessly!

@ojongerius ojongerius closed this Jul 22, 2018
@ojongerius ojongerius deleted the patch-1 branch July 22, 2018 04:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants