DEV Community: Marcelo C.

How I stopped declaring login in each of my 5k tests

Marcelo C. — Fri, 27 Feb 2026 19:26:44 +0000

Have you ever encountered a testing codebase that many portions are repeated over and over? We all have! Of course, I could be talking about DRY princples (Don't Repeat Yourself), but lets keep that aside for now and focus on a Cypress trick up it's sleeve that can go unnoticed for many senior devs: the global hooks.

And what do I mean by "global" hooks? They're called like that because you only declare them once and they're applied to all your tests instantly.

So let's get to the grain here: when installing Cypress it already comes with a file at created at cypress/support/e2e.<ts|js> level. This is usually where you declare some important commands imports that your E2E testing will need to access and run properly.

But it's also responsible for adding let's say before, beforeEach, or after, afterEach hooks that will be applied by all your tests. This can be responsible for login hooks, clean-ups to the database after the tests run, screenshots resolutions configuration -- a million of possibilities here.

I guess that the "global hooks" makes more sense now, right?

The challenge

At my workplace, I encountered the command to login, called cy.login, declared in each of the 5.634 tests that we have. For a while it bothered me a lot, because I always wanted to remove this codelines, and make my life easier with a simple e2e.ts file that handled all existing and new login logic for future tests.

But if I knew how it worked, why didn't I just do it already?

Becuase, for the first time (for me), I was dealing with a really complex system: a big chunk of the legacy tests ran with testIsolation: false. That meant that they only login once, and the it blocks don't load a new baseURL after each one is done. They do it all in one session.

Because? Well, that would be another story, so let's just accept their done like that for "system requirements" at the time.

Ok, so I basically needed:

before() → cy.login() beforeEach() → cy.login() only if testIsolation is true

Easy right? Not yet. The complexity resides because different spec families have different needs: different credentials, different environments, different session strategies, and different testIsolation settings.

There are two needs here to login:

Which login method?

cy.login(): Default specs with standard app with default credential.
cy.loginDemo(): Presentation specs with different environment, likely SSO or different credentials.
Custom (own login): Need specific credentials or totally different E2E tests outside enviroment.

When to login? (before vs beforeEach)

This is driven by Cypress's testIsolation setting:

testIsolation: true — Cypress clears browser state (cookies, storage) between each test. Session is lost → must re-login before each test.
testIsolation: false — Cookies persist across tests in the same spec → login once is enough.

Now, here is where the plot thickens. I had to declare folders, tests, paths that needed to be skipped (or not), because on the same folder I had testIsolation: true/false. So, follow me along:

1. Legacy specs (/legacy/ folder)

before() → skip entirely
beforeEach() → only call cy.login() if testIsolation is true

Legacy specs use specific credentials. If the global before() called cy.login() first, cy.session() would cache the wrong credentials, causing 500 errors when the spec then tries to login with different ones. So global before() is completely skipped. In beforeEach(), it only re-validates when state is actually cleared (testIsolation: true).

2. Training portal specs (/training/ folder) + Custom login specs

before() → skip entirely
beforeEach() → skip entirely

These specs manage their own login end-to-end. The global hooks stay completely out of the way. Some tests likely test login flows themselves or use role-specific credentials.

3. BEFORE_LOGIN_DEMO_SPECS

before() → cy.loginDemo() + cy.goToHome()
beforeEach() → skip (already logged in)

Login once per spec, reused across all tests. These are demo/presentation specs where re-logging in per test would be slow and unnecessary.

4. BEFORE_EACH_LOGIN_DEMO_SPECS

before() → nothing
beforeEach() → cy.loginDemo() + cy.goToHome()

Similar to above but login is repeated per test because testIsolation: true, the state is cleared between tests, so they must re-login each time.

5. LOGIN_DEMO_SPECIAL_SPECS

before() → nothing
beforeEach() → override baseUrl + timeout + idp_active env, then cy.loginDemo()

This spec runs against a completely different server, with an IDP/SSO active flag and a much longer timeout. The config must be set before each test because test isolation may reset Cypress config state.

6. Default specs (everything else, A.K.A the MOST important logic!)

before() → cy.login()
beforeEach() → cy.login() only if testIsolation is true

Standard app, default credentials. Login once in before(), then beforeEach() only re-validates the session if Cypress actually cleared it (testIsolation: true). If testIsolation is false, cookies persist and calling cy.login() again would navigate back to home, breaking any test that expects to be on a specific page.

The key insight: why before AND beforeEach?

You're asking "are you mental? why on earth would you declare login TWICE?", basically because:

before() → establishes the initial session (runs once)
beforeEach() → re-validates/restores the session if testIsolation cleared it

For specs with testIsolation: false, beforeEach() is a no-op (or returns early) because the session is still alive. For specs with testIsolation: true, beforeEach() must re-run the login to restore the cleared session — but it uses cy.session() internally which caches credentials.

Here's a sneak peek of how my e2e.ts file looks in it's (hopefully) final form:

And I basically removed the cy.login function from more than 1k files in my codebase, leaving me or any other engineer to not worry anymore about the login being declared at test level, it handles everything for me now, as it should.

What about you? Have you ever encountered a challenging and complex test codebase to deal with? What was the most difficult change you had to make? Leave me a comment, I would love to hear!

How to validate tables, rows or any content of an Excel file using Cypress

Marcelo C. — Fri, 31 Oct 2025 11:43:24 +0000

At the company I work for, we already have many test cases to validate a key behavior of our SaaS, which through the user downloads a table as an Excel file of the information needed. But there was a need to validate some edge cases, in which we also needed to validate that the content corresponds to what the table showed.

This would mean that Cypress needs to deterministically validate rows, numbers, names and even colors inside the Excel file set by our user flows. After some research, we basically came upon two Node.js libs: @e965/xlsx and exceljs.

While @e965/xlsx is mostly used for data content validation, as in validating a JSON rows straight from the sheet - exceljs is more focused for style assertion, meaning assertions like “is A1 light-green?”. All right, so now we could split keeps tests readable and fast.

Configuring @e965/xlsx library

First, wire up the configuration in Cypress. Head off to Node with cy.task(). It’s the official way to run filesystem code from Cypress tests: register tasks in setupNodeEvents and they’ll return values back to your spec.

Remember to also import the package on the config file:

//cypress.config.ts

const xlsx = require('@e965/xlsx');
...
...
...
      on('task', {
        async readExcelByPattern(pattern: string, timeoutMs = 15000) {
          const re = new RegExp(pattern);
          const end = Date.now() + timeoutMs;

          while (Date.now() < end) {
            const files = fs.readdirSync(downloadsDir).filter(f => re.test(f) && !f.endsWith('.crdownload') && !f.endsWith('.tmp'));

            if (files.length) {
              const { fullPath } = files
                .map(f => {
                  const fullPath = path.join(downloadsDir, f);
                  return { fullPath, mtime: fs.statSync(fullPath).mtimeMs };
                })
                .sort((a, b) => b.mtime - a.mtime)[0];

              await sleep(200);

              const wb = xlsx.readFile(fullPath);
              const sheet = wb.Sheets[wb.SheetNames[0]];
              const data = xlsx.utils.sheet_to_json(sheet);
              return { fileName: path.basename(fullPath), data };
            }

            await sleep(300);
          }

          throw new Error(`File .xlsx taht matches /${pattern}/ not found on "${downloadsDir}" inside ${timeoutMs}ms`);
        },

You can see that readExcelByPattern is the task we should call to validate the content like rows, tables and any information inside the Excel file. You can then define it inside your test context and methods (or define it globally over commands.ts if you plan to use it in many tests), but for a single test it should look something like this:

//my-testing-context.ts

  @step('Read downloaded excel values')
  readExcelDownloadedFile(
    pathToFile: string = 'excel_export/bugs/',
    fixture: string,
    fileName: string
  ): ExportPrintableReportContext<TParent> {
    cy.fixture(pathToFile + fixture).then((expected: any[]) => {
      cy.task('readExcelByPattern', fileName).then(({ data }: { data: any[] }) => {
        expect(data.length, 'Table length').to.equal(expected.length);
        expected.forEach((expectedRow, i) => {
          const actualRow = data[i];
          Object.entries(expectedRow).forEach(([key, expectedValue]) => {
            const actualValue = actualRow[key] === undefined ? null : actualRow[key];
            expect(actualValue, `Row ${i} - Column "${key}"`).to.equal(expectedValue);
          });
        });
      });
    });
    return this;
  }

As you can see it's pretty straight forward, it calls for a JSON file inside 'fixtures/excel_export/bugs/' that already has the values you want to validate and should be equal to the Excel file and executes a forEach of the Table length, and each row, which already awaits for a value.

And this is how it would look inside a test:

import { testContext } from '@/my-testing-context'

const testingContext = new testContext();

describe('example of reading excel files', => ()
  it('case 1', () => {
    testingContext.readExcelDownloadedFile('excel_export/bugs/', tk, 'Excel.xlsx');
  });
});

Basically it checked 171 rows of the file content and succeeded in 40 seconds.

For the second part of this tutorial, I'll expand on how to validate Excel colors as well. Happy testing!

How to get most out of cy.prompt() - 6 tips and tricks for your new AI tool!

Marcelo C. — Thu, 09 Oct 2025 13:54:06 +0000

I know, I know, Cypress has just announced a game changing feature with cy.prompt() that is going to change the way we test - or at least approach how we think of it. You're going to use Natural Language all the way to test your new app? Read through my recommendations then!

As a Cypress Ambassador I was lucky enough to be using cy.prompt for the past weeks and here are a few tips to make your testing and usage go a bit smoothly.

1) Start your phrase with the action or assertion you want

Instead of giving it an instruction like:

When the page loads, check that the header is seen and then click on Create button

Would be better to:

Wait 8 seconds for the page to load
Assert that the header is visible
Click on create button

Now Cypress will translate your instructions more easily - a hardcoded wait, followed by an assertion, followed by a click.

2) Try to separate instructions

The previous step gave it away already! Cypress prompt works as any other LLM - give clear instructions of what you want to do and it'll have a better chance to execute it.

Do not mix assertions, with force clicks, with reloads in the same line of action! The prompt needs to go through, so in a way try to act as a prompt engineer and step by step you'll get there.

3) You can have up to 20 steps for each prompt you execute

20 is the limit, ok. But that doesn't mean that you need to have 20 steps each prompt. Also, the more steps you add, the prone it is to ask for clarifications or make mistakes.

Think of it as this: each plain English text line you introduce is an abstraction layer, right? Do want an over-complicated test, or a easy to read through, understandable (for non-developers specially) test?

Lesser is better in some cases!

4) Leave some tests in prompt in order to validate flaky behavior

Got a new feature? Want to avoid brittle in your E2E test? Want to check for any weird behavior here and there? Then cy.prompt is your way to go! You can always leave your tests in plain English to see if the BDD/TDD behavior stays the same.

Remember: it works in both local and CI - but it only supports Chrome or Chromium browsers (Edge/Electron). Any others are out (sorry Firefox!). Leave it a few days or weeks in your CI in prompt scenario and see what happens.

5) Portability first?

For me any test that is written in plain English has a natural advantage over each other. It doesn't need to be refactored into any other programming language. So if you already know that the application you're working now is starting to be ported into another modern framework, leave your tests in prompt format. Your devs will appreaciate!

6) It's always cached

Another advantage with cy.prompt is that once it runs, it will cache the steps in order to avoid LLM interaction. But if you change one line in your prompt - wait 15 seconds instead of 8, for example - it will execute all over again.

Remember this to focus on speed and reliability in your tests!

How Cypress will revolutionize the use of AI in testing with cy.prompt()

Marcelo C. — Thu, 09 Oct 2025 10:28:22 +0000

Cypress has become the go-to testing framework for SDETs and QA engineers to validate modern web apps. It’s fast, reliable, and backed by a mature ecosystem—both in software updates and excellent documentation. Add to that the vibrant community building powerful plugins and extensions, and it’s clear why Cypress dominates the testing landscape.

Cypress is taking a bold step into AI-powered testing with the upcoming cy.prompt(). Unlike typical AI integrations that act as external copilots or rely on general-purpose MCP-style assistants, cy.prompt() adds the intent (what we want) built directly into the testing workflow.

This means no context switching, no juggling between an IDE plugin and your test runner. Instead, Cypress allows you to describe your intent in plain English, and the AI automatically generates selectors, actions, and assertions right inside your test.

It’s a shift from writing tests line by line to guiding your tests conversationally. Think less about cy.get() or cy.click() and more about telling Cypress what you want verified, letting the framework translate that into executable code.

Here’s a video demonstration of cy.prompt() in action:

This is the code that I used in the validation:

And here is what the prompt suggests of code locators right after is executed:

Also, you can leave the prompt as it is and push to your CI/CD pipeline:

With cy.prompt(), Cypress is no longer “just” a testing framework—it’s stepping into the AI-assisted development era. For SDETs and QA engineers, this means faster authoring, smarter locator handling, and easier onboarding for teams.

The possibilities of cy.prompt()

Cy.prompt focus on the intent: what we want, not how do do it. It's a great tool for non-developers, or anyone who doesn’t want to dive deep into app implementation.
Imagine writing the BDD (Behavior Driven Development) acceptance criteria directly into the test. You'll have the best of both worlds here, BDD criteria that is understood by all stakeholders (Project Managers, Product Owners), and the code being executed in the background.
TDD (Test-Driven-Development) is also covered for the developers. Imagine developing a feature until is ready and, step by step (word by word, line by line) it start to pass. Until is ready for deployment.
Portability is here: Need to refactor your project? Move from one programming language to another? Don't need to change a thing in your tests written in plain English, they can be easily shared, exported, or integrated across different systems.
Also, another great benefit here are the self-healing tests, they’re more resilient to changes in the DOM or selectors. This feature could fundamentally change how we approach automation.

The future of QA is not just code—it’s collaboration between AI and testers.

What are your thoughts?

Share, comment or connect with me directly in LinkedIn!