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

Jest needs disclaimers. #15135

Closed
jedwards1211 opened this issue Jun 19, 2024 · 4 comments
Closed

Jest needs disclaimers. #15135

jedwards1211 opened this issue Jun 19, 2024 · 4 comments

Comments

@jedwards1211
Copy link

jedwards1211 commented Jun 19, 2024

Page(s)

https://jestjs.io/docs

Description

The architecture of Jest has very significant consequences on what is and isn’t possible to do with Jest tests:

  • it’s pretty much impossible to share objects between testcases. Obviously Jest’s opinion is that we shouldn’t, and generally that’s a good opinion, but sometimes it’s necessary for performance reasons
  • Jest environments cause out-of-realm issues with globals that many developers aren’t accustomed to dealing with from day to day
  • Because Jest mocking is invasive, ESM compatibility is more complicated, and it’s still marked as experimental in the Jest docs. (Still!)

But many people don’t realize this and see Jest as a one-size-fits-all testing solution because it’s so popular. It’s not one-size-fits-all, and this is a poorly communicated fact. Jest needs a top-level disclaimer page that explains these limitations in its docs. The disclaimer should include:

  • use cases/developer needs that Jest is ideally suited for and aims to support
  • use cases/developer needs that Jest is not well suited for and does not intend to support
  • And examples of why Jest is better or worse than popular alternatives for given use cases.

You get PRs like #8708, which seems like something that's clearly contrary to Jest's philosophy, because people started using Jest before realizing how hard it would be to fulfill their needs with it.

There are projects for which Jest’s opinions about strong isolation are beneficial and projects where it isn’t. Most other testing frameworks I’m familiar with provide less test isolation, so they don’t have the limitations I mentioned above, and therefore may be more suitable for some projects.

I had one such project where it was impossible to achieve good performance testing ts-morph transforms with Jest, but my boss at the time was not very open to alternatives that would have saved us time and effort. I tried to persuade him it was by design but he failed to see that strong isolation is central to Jest’s design and not something the maintainers intend to change.

If only I had an official disclaimer from the project itself, I would have been more able to convince him what was in our best interest, and he might not have had such a dogmatic attitude about it to begin with.

Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 30 days.

@github-actions github-actions bot added the Stale label Jul 19, 2024
Copy link

This issue was closed because it has been stalled for 30 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

1 similar comment
Copy link

This issue was closed because it has been stalled for 30 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Aug 18, 2024
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant