Enable mocking a module in Cypress Component testing

[aaaaronmiles]

Hi everyone,
In our project we're using React Micro Frotends with single-spa framework. So, we've created a utility library that has all the components residing in it, and exports them so that they can be reused across multiple other Micro Frontends wherever required. I have started adding cypress component tests to this MFE-Components application using mount import.

I'm sharing the reproducible github repository link, please access them from here:
https://github.com/aaaaronmiles/MFE-App1
https://github.com/aaaaronmiles/MFE-App2
These 2 are some sample MFE applications that takes Button exported from MFE-ComponentUtil

https://github.com/aaaaronmiles/CypressComponentTesting
Here, there are 3 MFEs in it, MFE-RootConfig is the container, MFE-CommonUtil is the utility that has common methods exported, MFE-ComponentUtil is the Utility module, our area of interest, where I've to add cypress component tests for each component in it. I've already added a spec for Button component that imports 'isHidden' member from 'MFE-CommonUtil'.

You can run 5 of these MFEs locally by issuing npm start command followed by npm install, to execute them in action.

Here I wanted to mock 'isHidden' in tests. How can I achieve this mocking in unit tests.

But now I'm facing an issue where it imports a method from other utility module that is not available in MFE-Components and is throwing an error as shown in the below screenshot, when attempted to add tests. So I'm thinking of mocking it up somehow in cypress but I didn't find any related resources.

Question: I wanted something like moduleNameMapper available in Jest to mock out an entire module in cypress as well. Is there any such provision for us in cypress to stub out an entire module and simulate what it should return when it's called from tests. And whenever tests are running, the corresponding call showld be resolved to the mocked module instead of the original method implementation. Will cy.stub() help me in any way?

This is how my import in the component to be tested looks like (from external resource):
import {​ commonMethod }​ from "@org/commonUtil";

Appreciate your help, any thoughts are welcomed. Thanks for your time.

[vai0]

Bump - we're encountering the same need here. We want to migrate away from jest, but jest includes super useful mocking tools built-in.

We've attempted to use rewiremock to mock modules (since it appears its the only library that allows mocking in a webpack env) in our React components, but we're encountering the error from this stackoverflow

Has anyone been able to get around this?

[FelipeLahti]

I'm having the same issue here where I can't easily stub using cy.stub(module, 'method') for a module dependency in a component test.

Workaround below I came up with but it's not as clean as the way jest mock modules.

// component file
import { useToggle } from "./toggle";

export const App = () => {
  const toggle = App.useToggle();
  return (
    <div className="App">
      <h1>Toggle is {String(toggle)}</h1>
    </div>
  );
};

App.useToggle = useToggle;

// test file
it("stub works", () => {
  cy.stub(App, "useToggle").returns(false);
  mount(<App />);
  cy.contains("Toggle is false");
});

[pjmattingly]

Bump, I'd also like to see this.

[JessicaSachs]

I need to write up a more detailed response to this and our stance on module-based mocking.

Why is Cy different than Jest when mocking files?

The technical reason file-based mocking and mocking esm functions is possible for Jest is that Jest rewrites the code of your import functions and adds them to an object which you can then spy on or stub.

Cypress works fine with CJS and code that uses require or any actual object that has a property. In theory, you could take the same approach Jest does with Cypress Component Tests that use Webpack or Rollup. The reason Cy doesn't support it out of the box is because Cy is bundler agnostic, whereas Jest requires you to use a Jest-specific bundler. In theory, Cy could add a custom module transform step to accomplish the same behavior, but it would have to be implemented for each bundler/dev-server Cy supports.

Workaround: Put your esm code on an object and then mock the object.

For folks looking for a workaround, @FelipeLahti's workaround is recommended, you'll need to use a default export or other object-like container and pass that into cy.stub(myObj, 'methodName').

The reason this doesn't exist yet is that we haven't found it to be necessary. Initially, I thought it would be, but after building larger projects with it, we've found that many times it's not needed or there's a simpler way to accomplish the same thing.

Example

In the following code block, we're looking at an App component that renders an h1 tag with "Toggle is (true or false)".

// component file
import { useToggle } from "./toggle";

export const App = () => {
  const toggle = App.useToggle();
  return (
    <div className="App">
      <h1>Toggle is {String(toggle)}</h1>
    </div>
  );
};

To test this component, the test I'd write is: "When mounting the App, the value 'toggle is true' is shown by default". The first instinct people have is to say OK, but how do I change the value of the toggle to make sure that everything works?

To which, I say: Well, how would your users do it? Are your users using the UI to affect state change (ui-based testing)? Are your users other developers that are using this component (prop-based testing) and want to make sure it updates correctly when props change?

1. If you want to affect the state of useToggle and test that the component updates, I imagine you'd have a button or a prop.
2. You'd click on the toggle button or modify the prop.
3. Then, you'd be able to check that the App's "Toggle is (true/false)" string has been correctly updated.

The test we're writing is really about the App component responding to a toggle being updated somewhere and having a default value of (true or false). The fact that App is using useToggle is an implementation detail.

On file-based mocking in general

Jest's file-based mocking is generally out of necessity of preventing expensive bits of third party code from executing, however for a component to "look and feel" correct, having real dependencies is what you want 99% of the time. If you're depending on something like Material UI, you definitely want to render those components or else your app/components will look and behave incorrectly. Your code should be as production-like as possible.

cy.intercept

Making things like external network requests and mocking responses is a common reason folks like to file mock. Instead of mocking at the file-level, we suggest mocking at the environment level and use tools like cy.intercept.

So, TLDR

1. To mock/stub, export an object in addition to named methods and stub that.
2. You should try and avoid mocking and stubbing.

Finally, tell us your use-case

We obviously don't speak for a majority of developers, and Cypress Component Testing's API is still in its early days. We've been able to avoid module-based mocking and stubbing completely in our usages of Cypress Component Testing with close to 0 pain.

That does not mean a first-class API isn't warranted.

I'd like to keep this discussion going and understand what kinds of use cases require file-based mocks. Please share :-)

[Jamongkad]

Just to keep this discussion going I have a use case that might generate some interest.

//CommitList.tsx
import { useLocation } from 'react-router-dom'

export const GithubRepoApiContextProvider = ({ children }: any) => {
  const [page, setPage] = useState(1)
  const { pathname } = GithubRepoApiContextProvider.useLocation()
  const { commits, error } = useGithubRepo({ page, pathname })

  return (
    <GithubRepoApiContext.Provider value={{ commits, error, page, setPage }}>
      {children}
    </GithubRepoApiContext.Provider>
  )
}

GithubRepoApiContextProvider.useLocation = useLocation;

//CommitList.test.tsx
it('test', () => {
    mount(
      <GithubRepoApiContextProvider>
        <CommitList />
      </GithubRepoApiContextProvider>
    )

    cy.intercept(
      {
        method: 'GET',
        url: '/repos/m3db/m3/commits*',
      },
      {
        fixture: 'repo-api',
      }
    ).as('getCommits')
    cy.stub(GithubRepoApiContextProvider, 'useLocation').returns({ pathname: '/m3db/m3' })

    cy.get('[data-testid=commit-card]').should('exist')
  })

I've gotten it to work with the Component test runner but I have to admit the code feels kinda hacky compared to the module mocking of Jest. I just wanted to highlight the use of mocking a React hook from a 3rd party module.

[juan-m-medina]

I think the argument against mocking is impractical for many scenarios.
I work with a payment system where multiple providers can be injected, but there is a single boolean function that determines whether a payment type is available from the provider.
The way the solution is described here, I would have to write code to manipulate those calls using intercept and having very implementation specific setups for each case. But if I can mock the actual true/false function instead, I have a less fragile test where I can easily test all the relevant scenarios.
As noted, what I want to check in this particular case is whether the UI for a particular result is generated with the assumption of the process returning what is needed. Faking or making the calls is too expensive for a test of this nature.
Care to explain how in your approach this is doable? Maybe I am misunderstanding what you did.
In the meantime, spending a ton of time trying to get rewire libraries to do this type of mock.

[alveshelio]

Hi

In my case I'm using a library to handle translations and I have this simple <LanguageSwitcher /> component.
I've tried to follow the example and this is what I have

import { ReactElement } from 'react'
import Link from 'next-multilingual/link'
import { useMessages } from 'next-multilingual/messages'
import {
  normalizeLocale,
  getActualLocales,
  getActualLocale,
  hydrateUrlQuery,
} from 'next-multilingual'
import { useRouter } from 'next/router'
import { Button, ButtonProps } from '@chakra-ui/react'

export const LanguageSwitcher = ({ ...buttonProps }: ButtonProps): ReactElement => {
  const messages = LanguageSwitcher.useMessages()
  const { pathname, locale, locales, defaultLocale, query } = useRouter()
  const actualLocale = getActualLocale(locale, defaultLocale, locales)
  const actualLocales = getActualLocales(locales, defaultLocale)
  const href = hydrateUrlQuery(pathname, query)
  const otherLocale = actualLocales.find((l) => l !== actualLocale)
  const localeTranslationKey = (): string => normalizeLocale(otherLocale).split('-').join('')

  return (
    <Link href={href} locale={otherLocale} passHref={true}>
      <Button as="a" {...buttonProps}>
        {messages.format(localeTranslationKey())}
      </Button>
    </Link>
  )
}

LanguageSwitcher.useMessages = useMessages

And in my test I have:

import { LanguageSwitcher } from '@components'

describe('LanguageSwitcher', () => {
  it('should display English', () => {
    cy.stub('LanguageSwitcher', 'useMessages').returns({ format: (key: string) => 'JoJo' })
    cy.mount(<LanguageSwitcher />)
  })
})

However, when I try to run this test I get this error:
TypeError: Cannot use 'in' operator to search for 'useMessages' in LanguageSwitcher at isNonExistentOwnProperty

[blindfish3]

@JessicaSachs - what do you recommend with respect to component tests in Cypress? I'm currently trying to figure out the solution to a broken module import in a component test. This could well be an issue in my configuration (getting Cypress and Sveltekit to play nicely together is proving interesting 😅); but in the context of a component test I don't actually need the method from this module to be imported. In fact it's something that it would make more sense to mock and spy on.

This feels like a situation in which mocking module imports might make sense.

[Dante-dan]

Sometimes, we need mock module which from dependencies

[glomotion]

Im a little late to the party here - while I agree, we should mock as little as possible - sadly, mocking is an integral part of unit/integration testing (atleast it is for us). Mocking helps us remove complicated external functionality which is otherwise not relevant to the functionality that we might want to test out inside of a React component (which helps keep our tests light, and easier to read and understand - because mocking (module rewiring) can save us from needing a slew of cy.intercept() calls in the setup of a test suites).

I've long struggled with this within cypress component testing (cypress uses sinon under the hood, which is NOT a module rewirer, like jest's jest.mock()), but a little while ago found an awesome little trick - which will allow you to mock any ESM module that's imported into the components you're looking to test - so long as you use babel to compile your ESM components.

https://github.com/asapach/babel-plugin-rewire-exports this little babel plugin works a treat (as long as you still use babel to compile, and not some fancy rust-based compiler like SWC). The other nice thing about this tooling, is I find the rewiring syntax incredibly simple compared to jest's convoluted (IMO) module rewiring functionality and (ridiculous mock variable naming) rules.

here's some demo code which i make available to other engineers in my team, who ask me how module rewiring can work inside of cypress:

Rewirable imports from an NPM library:

// ./rewirable-imports.ts
import { SimpleText } from '@imtbl/design-system';
export { SimpleText };

The test component:

import { css, cx } from '@emotion/css';
import { SimpleText } from './rewirable-imports'; // @NOTE SimpleText is a component taken from an npm library
import { useSimpleHook } from './simple-number.hook';

interface MooPropTypes {
  name: string;
}

export const demoFunction = () => 'how now, brown';
export const demoObject = {
  moo: 'cow',
};
export const demoString = 'i wish i could be rewired ...';

export function Moo({ name }: MooPropTypes) {
  const { number } = useSimpleHook();
  return (
    <>
      <div
        className={cx(
          'moo',
          css`
            background: gold;
          `,
        )}
      >
        {name} {demoFunction()} {number} {JSON.stringify(demoObject)}{' '}
        {demoString}
      </div>
      <SimpleText>demo body text here</SimpleText>
    </>
  );
}

The test which does some rewiring:

import { mount } from '@cypress/react';
import { cy, describe, it } from 'local-cypress';

import * as MooFile from './Moo.component';
import { Moo } from './Moo.component';
import * as RewirableImports from './rewirable-imports';
import * as SimpleNumberHook from './simple-number.hook';
const { rewire$demoFunction, rewire$demoObject, rewire$demoString } =
  MooFile as any;
const { rewire$useSimpleHook } = SimpleNumberHook as any;
const { rewire$SimpleText } = RewirableImports as any;

describe('rewire tests', () => {
  it('test out rewire', () => {
    // @NOTE: rewire various things:
    rewire$demoFunction(() => 'holy smokes batman!');
    rewire$useSimpleHook(() => ({ number: 48 }));
    rewire$demoObject({ aww: 'yeah!' });
    rewire$demoString('i can totally rewire');
    rewire$SimpleText(() => <section>this is a stub DS component</section>);

    mount(<Moo name="POW!" />);
    cy.contains('48').should('exist');
    cy.contains('this is a stub DS component').should('exist');
    cy.contains('i can totally rewire').should('exist');
  });
});

Its also worth adding, that I have just recently migrated a tonne of cypress 9.x component tests across to cypress 10.x and everything still works nicely.

SIDENOTE: thank you to the cypress team for the amazing 10.x release. It is waaayyy nicer than i was expecting. Definitely a HUGE improvement! :D

[juan-m-medina]

I must agree that solutions that require the codebase to be rewritten are not really great solutions.
Mocking a module for testing is not an issue.
Mocking a module that is being used by something internally is a big issue, because the current uses change the module for uses defined inside the test, but not for uses that happen as part of loading a component.

[glomotion]

It means we need change our source code to adapt for component test. this is additional cost.

I’m guessing you’re referring to the npm component rewireable imports file. Agreed this is not ideal - but we find that we only have to do this when we want to rewire an npm component import - which (for us) is very rare.

most of the time zero changes to source code are neccissary.

[glomotion]

I must agree that solutions that require the codebase to be rewritten are not really great solutions.
Mocking a module for testing is not an issue.
Mocking a module that is being used by something internally is a big issue, because the current uses change the module for uses defined inside the test, but not for uses that happen as part of loading a component.

I don’t think I follow this argument. :P

[juan-m-medina]

Below I a posting an idea of what I mean to do, that I have not been able to get to work (using WebPack 5 and Babel 7.
The Component is a vanilla Web Component that when initialized wants to avoid making an expensive call where we want to check for that call to return true/false.
The comment above from @JessicaSachs about using cy.intercept to address this means I would have to mock the entire expensive call behavior, with objects etc... times the amount of calls to intercept (which in my case is 3).
Instead, I want to mock the calling method to return true or false to test the behavior of the UI when the third party expensive call returns true/false, which is mostly used to decide to display or not some UI related to it and do further processing.

// service.js
export class Service extends BaseService {
  methodThatWantsToBeStubbed() {
    expensiveCallThatUsuallyReturnsTrue();
  }
}

// consumer.js

import { Service } from './service.js`;
export  class Consumer extends Component {
  init(config) {
    this.service = new Service();
    this.displaySelf = service.methodThatWantsToBeStubbed();
  }
}

// consumer.cy.js

import { Consumer } from 'consumer.js';
import { Service } from 'service.js';

describe('Consumer', ( ) => {
  beforeEach(( ) => {
    
    // HERE I WANT TO MAKE Service or Service.prototype.methodThatWantsToBeStubbed A STUB
    // SO I CAN FORCE IT TO RETURN TRUE OR FALSE    
  });
  
  it('displays the expected UI when the service initialization returns true', ( ) => {
    // check it shows the items created when call to methodThatWantsToBeStubbed returns true
  }); 

  it('does not display the expected UI when the service initialization returns false', ( ) => {
    // check it shows the items created when call to methodThatWantsToBeStubbed returns false
  }); 
});

What I have found so far:

• Flat node rewire does not appear to work due to the Babel translation from ESM to CSJ modules (I have to support old browsers, particularly Safari 10 in mobile).
• babel-plugin-rewire does not work with Babel 7. Babel 7 Support?  speedskater/babel-plugin-rewire#209
• So far, I have not been able to get babel-plugin-rewire-exports, but this is where I am concentrating my efforts.

I really am having quite a hard time trying to figure out why this behavior is not supported out of the box. I am surely missing something, but after days of trying stuff I am about to look for other solutions.

[juan-m-medina]

Finally, got to work with the babel-plugin-rewire-exports.
I must be missing something in the config for Cypress.
When I check the value of the module on the webpacked code, the module contains the rewire/restore functions.
However, when I do the same inside the .cy.js test file, the module seems to be loaded from the file, not from the webpacked bundle, and thus the module does not have the rewire/restore functions.

[juan-m-medina]

Well, unfortunately, after a full week of trying lots of approaches, I am giving up on working around the lack of proper stubs on cypress.
We really want to be able to stub functionality without having to jump through the hoops, so I'll be trying jest plus possibly puppeteer for a first pass.
If anyone has an actual end-to-end working example that can be looked at where cypress works, let me know. Piecemealing a solution from the comments around did not yield results for me.

[muratkeremozcan]

I can't think why I would want to mock the child components in a parent, but I would also like to see it work.

No issues with with mocking functions in another component. When mocking the children, the mock doesn't seem to have an effect.

Here's a WIP PR with reproducible code.
https://github.com/muratkeremozcan/tour-of-heroes-react-cypress-ts/pull/155/files

[fringd]

Just want to agree that mocking is critical for testing code. Especially old legacy code that you're going to need to refactor... which is exactly the kind of code you REALLY need to write tests for. You're right that architecting your code so mocks aren't needed is best. But we know that. Reality is messy and we need a testing tool for reality. please and thanks!

[christian-bromann]

For people who are still looking for this feature: mocking of modules and dependencies just landed in WebdriverIO with a similar syntax as used in Vitest or Jest: https://webdriver.io/docs/component-testing/mocking.

[jacobcoro]

Isn't it kind of rude to promote your project on another's repo?

[jordanpowell88]

We are working on finding an adequate solution for this problem. It's a very difficult technical problem to solve but we hope to provide some solutioning in the relatively near future.

[zsidnam]

+1 to this as I recently came across a big use case when looking into zustand:

In general, I am a huge proponent of behavioral testing and mocking as little as possible. However, I have found that it is often extremely convenient, if not necessary, to be able to pre-populate context providers or global state providers with specific values in order to test a component that relies on that state in isolation. If I'm using a component-scoped state management solution like React Context or Redux, this is easy to do in component tests.

However, our team has recently been looking into module-scoped state management solutions like zustand, and as far as I can tell, there is no way to pre-populate or reset the store on a per-test basis without mocking the library. (See zustand's testing documentation for an example: https://docs.pmnd.rs/zustand/guides/testing).

I'm curious if anyone else has had success testing applications that use zustand or similar module-scoped solutions. In an ideal world, all of our component tests would be completely agnostic to implementation details, but in practice, I've found that difficult to do in some areas of the application without mounting essentially the entire app.

[angeloderivco]

Just adding a use case here (and hopefully someone will know a good workaround) for a scenario which cy.intercept wouldn't be able to fix. We have a component dependent on the url's query params. We use the 'useSearchParam' from next/navigate and without mocking, solutions will be a bit hacky to say the least.

[thminggg]

A solution of stubbing a module comes from https://glebbahmutov.com/blog/stub-react-import/
Demo repo: https://github.com/thminggg/cypress-playground

TL;DR

1. Install babel presets and plugin
   npm install --save-dev @babel/plugin-transform-modules-commonjs @babel/preset-env @babel/preset-react cypress

2. Update cypress.config.js

const { defineConfig } = require("cypress");

module.exports = defineConfig({
  component: {
    devServer: {
      framework: "create-react-app",
      bundler: "webpack",
      webpackConfig: {
        mode: "development",
        devtool: false,
        module: {
          rules: [
            {
              test: /\.(js|mjs|jsx|ts|tsx)$/,
              exclude: /node_modules/,
              use: {
                loader: "babel-loader",
                options: {
                  presets: [
                    "@babel/preset-env",
                    ["@babel/preset-react", { runtime: "automatic" }],
                  ],
                  plugins: [
                    [
                      "@babel/plugin-transform-modules-commonjs",
                      { loose: true },
                    ],
                  ],
                },
              },
            },
          ],
        },
      },
    },
  },
});

3. Stub inside the test src/App.cy.js like this

import React from "react";
import App from "./App";
import * as Utils from "./utils";

describe("<App />", () => {
  it("renders", () => {
    cy.stub(Utils, "getToken").returns("Mock token"); // stub the return value
    cy.mount(<App />);
  });
});

src/App.js code:

import logo from "./logo.svg";
import "./App.css";
import { getToken } from "./utils";

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <p>
          Edit <code>src/App.js</code> and save to reload.
        </p>
        {/* Display token value */}
        <p>{getToken()}</p>
        <a
          className="App-link"
          href="https://reactjs.org"
          target="_blank"
          rel="noopener noreferrer"
        >
          Learn React
        </a>
      </header>
    </div>
  );
}

export default App;

utils.js code

export const getToken = () => {
  return "Default token";
};

Minimal repo setup to try out:

Create React App:
npx create-react-app my-app

Go to directory and install packages:
npm install --save-dev @babel/plugin-transform-modules-commonjs @babel/preset-env @babel/preset-react cypress

Add Cypress npm script "cy:open": "cypress open" in package.json:

{
  "name": "cypress-playground",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@testing-library/jest-dom": "^5.17.0",
    "@testing-library/react": "^13.4.0",
    "@testing-library/user-event": "^13.5.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "react-scripts": "5.0.1",
    "web-vitals": "^2.1.4"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "cy:open": "cypress open"
  },
  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  },
  "devDependencies": {
    "@babel/plugin-transform-modules-commonjs": "^7.23.0",
    "@babel/preset-env": "^7.22.20",
    "@babel/preset-react": "^7.22.15",
    "cypress": "^13.3.0"
  }
}

Open Cypress: npm run cy:open

Click through the Cypress UI to add first test: src/App.cy.js and yields configs:

• cypress.config.js
• cypress/support/commands.js
• cypress/support/component-index.html
• cypress/support/component.js

Follow the steps in TL;DR section above ⬆️

[a-vershinin]

And what about apps which do not use Babel ?
For example, if you know Next JS is dropped babel since nextjs@13 and recommended new approach based on SWC. So we can't use Babel if want to have new features and have good speed of app.
Just for remind, today we already have nextjs@14

[tar-aldev]

As an example: if you import next/headers it will break in cypress CT. In jest I could just mock it and it works perfectly fine...

[bobby91560]

Did you find something to make it works in nextJS since ?