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

Open
jedwards1211 opened this issue Jun 19, 2024 · 0 comments
Open

Jest needs disclaimers. #15135

jedwards1211 opened this issue Jun 19, 2024 · 0 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant