Jest support

[newtack]

Jest has surpassed mocha in terms of performance as well as some features (snapshot testing specifically).

Is mocha hard-coded to Cypress or is it possible to have support for Jest in the not too distant future?

[brian-mann]

Mocha is definitely hard-coded into Cypress, although Mocha really only provides the testing structure and things like beforeEach, after hooks.

What would you gain from having Jest?

The performance gains would be negligible, as Cypress is used mostly as an integration / e2e testing tool, and not so much unit testing. The vast (upwards of 99.99%) of compute time is spent driving the browser and loading the application, and Mocha does 0% of that.

[newtack]

Thanks for the quick response.

1. Performance: Parallelizing tests will be important, whoever will be in charge of it (cypress,mocha/jest, developer). Is there a way to parallelize tests? As the # of integration tests goes up, it will become important to be able to run tests in parallel. I'd agree that the micro speed differences between mocha and jest are not important, but an answer to executing tests in parallel is
2. Snapshot testing. http://benmccormick.org/2016/09/19/testing-with-jest-snapshots-first-impressions/ As I understand it, this provides a way to more easily verify state changes and regressions.

[brian-mann]

I think the confusion comes because Cypress runs in the browser - not node.

1. As such you cannot parallelize tests at the browser level - this can only be done at the OS level. Only a single application can have focus in an OS, and browsers will perform differently when not in focus. Additionally the DOM and the URL are global state and therefore you cannot run two tests that both use this at the same time. Currently users which "parallelize" their Cypress tests spin up multiple docker containers for each spec file, but they run in complete isolation, and then the results have to be manually aggregated together.
2. Snapshot testing uses node fs API's that will not run in the browser. Sure we could port these as we have with cy.readFile and cy.writeFile but what's the point? You can already use jest in node to do this - I don't see any benefit to be able to do this in Cypress. Cypress is primarily an integration / e2e tool.

[xogeny]

@brian-mann There is an interesting argument for snapshots that I make in this article. It would certainly make that kind of testing a lot easier.

[NoMan2000]

I think the main problem is context switching. Jest/Jasmine and Mocha/Chai/(Insert Ten Thousand other plugins) style assertions are kind of close, but also very different. I hate having to write two different sets of tests, even though it's a minor gripe, anything that makes testing easier is a win in my book.

[IgnusG]

I agree with @NoMan2000. Mocha, chai etc. just provide the testing environment and switching to jest in these terms wouldn’t provide much benefit, but cypress.io claims to be dependency free, which is just not true.

If a project doesn’t use mocha you have to use it in your cypress code now. Having cypress independent of these or providing some kind of abstraction level (like mocha-cypress-adapter, jest-cypress-adapter) would be beneficial so that the developer isn’t forced to either switch from jest to mocha or constantly having to remember which testing framework he is writing his tests in right now.

That goes a long way to making it much more developer friendly

[bondz]

This would make it easier especially for React projects where the goto testing framework is Jest, writing integration tests in Mocha just feels weird. The adapter suggestion by @IgnusG would be a really good feature.

In the mean time, this article is helpful.

[thibaudcolas]

IMHO this issue should be re-opened – the real value in supporting Jest with Cypress is in the lower context switch between writing assertions for E2E tests and unit tests as @NoMan2000 states #281 (comment). I don't think it's a minor thing; if you have hundreds or thousands of test cases to maintain across potentially multiple projects, saving yourself of one context switch can make a big difference.

For unit tests, I don't know of any reasons why one would prefer Mocha + Chai + Sinon over Jest (easier to setup, faster, well documented, snapshot tests, better async support, built-in coverage) – so if one wants a single test definition style, it would be much better to consolidate on Jest than Mocha.

Also relevant: #772.

How does that sound @brian-mann?

[jennifer-shehane]

We have decided to reopen this issue. We have reevaluated this and decided it will be part of our future Roadmap. Things change quite a bit in 2 years.

No work has been done for this. It is still in a proposal phase.

[SimenB]

Hiya, Jest team member here 👋

I'm not sure what concretely this issue entails, but if it's 'replace mocha with jest', note that Jest itself does not run in a browser. However, certain parts of it does:

• jest-circus: the framework itself, which includes the globals (describe, test etc). That's where the implementation for tests, skipping, grouping etc lives (default runner in jest today is jasmine, but that will change, and circus is the next version)
• expect: the extendible assertion library
• jest-mock: spies and stubs

Happy to field questions (and land changes in Jest) to help whatever you want to happen happen :)

As an aside, I'd also love for us to be able to run Cypress tests on CI using Jest, e.g. https://twitter.com/kentcdodds/status/954200231393898496?s=19

[SimenB]

Concretely from the OP, snapshots are hard as they use the file system. Might be we can make inline snapshots work, or use something like https://twitter.com/suchipi/status/1054249716194566145?s=19 to implement it

[alexkrolick]

Seems like you can call expect within a Cypress callback, but it doesn't integrate with the Chai-based reporter except when an error thrown by a failed assertion is caught by the test runner:

https://github.com/alexkrolick/cypress-test/blob/master/cypress/integration/index.spec.js

[SimenB]

Seems like you can call expect within a Cypress callback, but it doesn't integrate with the Chai-based reporter except when an error thrown by a failed assertion is caught by the test runner:

Yeah, that's expected, it's not really a goal for Jest to report passing expectations. That might change in the future, though: jestjs/jest#6616.

---

BTW, if it was unclear, jest-circus contains describe, it and test, but they are not globals. Jest adds these functions to the global scope, but Circus itself just exports the functions. So if it's a goal to move away from globals at some point, Circus is very much capable of that.

[newtack]

Do you have an updated estimate when/if this is going to be added?

[jennifer-shehane]

This issue is still in the 'proposal' stage, which means no work has been done on this issue as of today, so we do not have an estimate on when this will be delivered.

[pauldcomanici]

Personally I would like to see jest support in cypress for the main reason that I can use same matchers that i have in my UT.

When testing with cypress I do not care about snapshot testing as this shouldn't be done when doing e2e/integration testing.

Right now is very confusing and it adds extra effort when writing tests as my UT are done using Jest matchers and cypress uses chai matchers.

[phongnd39]

I just created a simple small package to add Jest expect matchers and syntax to run with Cypress and Chai-based reporter here: https://github.com/phongnd39/cypress-jest-adapter. The mock assertions functions are still based on Chai-Sinon, though.

I do hope that Cypress add jest support out-of-the-box or give an option for us to choose the testing framework soon.

[jennifer-shehane]

Hey @phongnd39, can you add your plugin to our docs on the plugins page?

[phongnd39]

Hi @jennifer-shehane , I have created a pull request to Cypress plugins pages. Can you help me review it?

[phongnd39]

I have just updated my package https://www.npmjs.com/package/cypress-jest-adapter with some new assertion methods to assert elements returned from Cypress command more quickly. Can do assert like expect($ele).toHaveClass(className: string) or expect($ele).toBeHidden(), and you can find more in the docs
Please feel free to try and open issue if you have any 😄.

[PascalAOMS]

Looking forward to Jest implementation myself coming from Vue CLI.
Not interested at this stage to learn Mocha.

[csalvato]

Following this thread. Consider this a +1 for the feature/issue @jennifer-shehane 🙏

[sseppola]

To add to @TheJaredWilcurt's comment, Jest seems much more popular considering downloads, forks, and contributors compared to mocha and chai. However, I get it if you need to wait for a new Jest api jestjs/jest#6616 (comment). I'm just trying to say that the effort wouldn't be wasted on an issue like this as Jest is carrying significant momentum.

Source: npmtrends jest vs mocha vs chai

[danantal]

Any news on this? I think that a lot of people are eager for Jest support.

Just a 👍 on what everyone is saying above.

Also, not thinking about this out of the box will always be a bit weird. For example - the latest release of 4.6.0 has a pretty cool inline source map error reporting built in. However, when using the Jest Adapter Plugin - the errors look like this when doing an expect like so:

expect(nullValue).not.toBeNull()

[tpischke-bedag]

I am evaluating Cypress for our Angular development team. Since we are using Jest for unit testing, this issue is of great interest. It is certainly not ideal if we must use Mocha/Chai/Sinon APIs for E2E Testing and Jest APIs for unit testing, due to context switching and the need to learn two APIs. That need not necessarily stop us from adopting Cypress, but it will certainly be a negative factor in the evaluation.

[csalvato]

We adopted Cypress despite the fact that it uses Mocha. We love the framework, but I would be lying if I said that having to know Mocha and Jest wasn't a significant source of friction 😬

[vinayakkulkarni]

Would really appreciate if there was an example using Ava

import test from 'ava';

test('Page exists', async (t) => {
  cy.visit('/').then(async function({ document: { body } }) {
    t.true(body.includes('<h2 class="mt-6 text-2xl font-extrabold leading-9 text-center text-gray-900">Welcome</h2>'));
    done();
  });
});

something like this?!

[samlucax]

There are some projects using Jest & Cypress integration:

https://github.com/bahmutov/cypress-and-jest
https://github.com/cypress-io/cypress-and-jest-typescript-example

Can we consider as a Jest support or it isn't official?

@brian-mann @jennifer-shehane

[gabycasper007]

I'm highly interested in this feature as I can't live without Jest

[Faithfinder]

So I suppose comments are needed to increase priority on this. Here's one.

[hakankaraduman]

It would be amazing to have jest in Cypress.

[jennifer-shehane]

If you have interest in this feature, please add a 👍 emoji to the main comment of the issue. If you have some more substantial comments to make about how the feature should be implemented, please leave a comment. Otherwise the comments become a lot of noise for others following the issue. Thanks!

[sachet-mittal]

I think there is a significant interest to have jest support in Cypress. Is it possible to add it to the roadmap and get an ETA for it?
We want to use Cypress for our project but we dont want to add another tool(Mocha) to our repo Jest is already used for unit testing.

[AverageHelper]

I've noticed that TypeScript begins to get finicky with projects that use both Cypress and Jest. I'm presently trying to figure out how to properly juggle Jest and Mocha types in the correct folders.

Would first-party Jest support solve this? If there were, say, some way to configure Cypress to utilize Jest types and constructs, rather than Mocha's, I expect typing issues like these would disappear.

[calebeby]

@AverageHelper you can handle conflicting global types by making a separate tsconfig.json for your cypress folder, then you can use project references

[AverageHelper]

then you can use project references

Been working on that today. Still juggling.

I've got my root tsconfig set up to reference other tsconfig files that themselves define the file blobs to which they should apply, each also inheriting common config options from a separate base tsconfig file. My Cypress folder has its own tsconfig file, referenced in the root one as a separate project.

Now everything except my Cypress files has type conflicts 😅

EDIT: Got it. It just took a bunch more juggling 😁

[AndrewLeedham]

I am in a similar situation trying to get TypeScript to work with both Jest and Cypress/Mocha. The examples provided assume a cypress/integration folder. However, in the project I am working on we group everything related to a component into sub-folders, so ideally I would have something like:

./components/Button.tsx
./components/Button.test.tsx
./components/Button.cypress.test.tsx

Using project references for this would work if it was just loading a web page in the cypress test, but as soon as you start importing say ./components/Button.tsx the project references approach falls over as it would need to have definition files built out for the source (The reason you might want to import the component is for https://docs.cypress.io/guides/component-testing/introduction.html#React).

So if I could remove the need for project references by using Jest for both unit and integration tests, that would be 👨‍🍳 😗

[caeserbala]

2021 still we are expecting jest to be incorporated with cypress .

[vinayakkulkarni]

We don't require Jest, Mocha does the job successfully!

[straurob]

2021 still we are expecting jest to be incorporated with cypress .

Although I also voted for this issue, this is still an open-source project which leaves you with the following options:

1. Wait until someone or some team implemented the feature.
2. Start working on it by yourself and creating a pull request, thus contributing to the project.

Commenting and "expecting" others to solve this issue is imho not the way to go. Please let's focus with regards to content.

[dalelotts]

2021 still we are expecting jest to be incorporated with cypress .

I suppose there is also the option to pay someone to add the feature.