What’s the right way to unit test utility functions in Cypress JS?

General Discussions
, ,
1

I’m using Cypress JS testing in my React application and really enjoying it so far. However, I’m now trying to unit test a simple utility function like this range function:

const range = (start, end) => {
  const ans = [];
  for (let i = start; i < end; i++) {
    ans.push(i);
  }
  return ans;
};

I attempted to test it in cypress/integration/helpers.spec.js like this:

import { range } from 'utils/helpers';

context('Helpers', () => {
  it('range', () => {
    expect(range(3).toLocaleString.equal([0, 1, 2]));
    expect(range(1, 3).toLocaleString.equal([1, 2]));
  });
});

But I get an error: Cannot find module ‘utils/helpers’

My questions are:

What’s the right way to import and test standalone functions using Cypress?

  1. Is Cypress JS testing the right tool for this kind of unit testing, or should I use something else like Jest?

  2. If Cypress is viable, how should I structure my code or config to allow utility imports?

I’d prefer to stick with Cypress for consistency, but open to suggestions if there’s a better fit.

2

I’ve been working with Cypress JS testing for a while, and yeah, I hit this wall too when I tried unit testing utility functions like range() early on. The issue usually comes down to how Cypress resolves modules, it won’t recognize paths like 'utils/helpers' unless you’ve configured Webpack or added alias support via something like tsconfig-paths.

I found it easier to just switch to relative imports like ../../../src/utils/helpers.js, and that solved the import errors.

That said, for simple logic or pure functions, Cypress JS testing isn’t the most efficient. I use Jest for unit testing, it’s lightweight, fast, and doesn’t require spinning up a browser just to test a for loop. Cypress still handles my integration and UI flow tests though.

3

Same here, been deep into Cypress JS testing for the last year, especially for end-to-end stuff. Just wanted to add, Cypress is great for UI and behavioral validation, but when you’re dealing with standalone functions like range(), Cypress kind of overkills it.

About that 'utils/helpers' import error, it happens because Cypress doesn’t share the module resolution strategy your app might have set up (like aliases in Webpack or Vite). Relative imports are a workaround, but it’s not ideal for maintainability.

Personally, I run Jest in parallel for unit testing and reserve Cypress JS testing for what it does best: validating how everything works together in the browser. Keeps the stack clean and your test runs fast

4

I’ve gone a bit deeper with Cypress JS testing and tried to make it a one-stop shop, including unit testing with component tests in a React setup. You can technically test utilities like range() by placing them under cypress/component and using Cypress Component Testing mode, but it needs some upfront config. You’ll also have to ensure ES modules are supported or stick with relative paths to prevent those alias import errors.

But let’s be honest, once you scale a bit, it just becomes clear that using the right tool for the right job pays off. Jest handles utility tests without any setup hassle, and Cypress JS testing takes care of flows that need a browser context. That separation has worked best for me in the long run