You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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:
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.
The text was updated successfully, but these errors were encountered: