Basically I have custom commands for API calls to create environment needed for tests. So I have something like this:

Cypress.Commands.add('getSomeDataById', (dataId, userId) => {
    cy.request('GET', '/myEndpoint')
        .its('body')
        .then((body) => {
            body.data.forEach((data) => {
                if (data.id === dataId && data.userId === userId) {
                    cy.wrap(data).as('data');
                }
            });
        });
});

then in the next command I have:

Cypress.Commands.add(
    'someOtherCustomCommandForCreation', () => {
        cy.get('@data').then((data) => {
            // For this data do that
        });
    },
);

I would say that using aliases to implicitly pass data between two commands is an anti-pattern. Chaining off the previous subject is definitely the better option here.

It's probably best to keep alias usage to a minimum, but there are definitely use cases for it. We have cases where we use it a lot like you are here 🙂 A better approach, however, would be to use

{ prevSubject: true }

on the second command, then chain them together. But I do realize this is not always convenient. In my case we have multiple commands that make use of an object that we build up as the test progresses, which we alias. (We collect data during the test, then do a lot of assertions on a confirmation page at the end of the test.) A global variable will work too, and maybe some clever architecture will get you there.

I have seen use-cases where you need to build up some data in the background across a whole test. We have an internal Cypress plugin to generate very particular reports for a formal validation/documentation system we have to use in our industry, and we build up the entries for those reports during the lifecycle of a test using a custom command. The statefulness of that report generation is contained within normal JS variables in the command file, not aliases. Definitely avoid if possible though - global state is a big hammer.

It's hard to reason through it without spending an hour screen-sharing a use case, but suffice it to say one case where I will choose it is if it allows the test file to be easier to read. State is less problematic in tests (vs full applications) due to their short run times.

Yeah that's basically how we arrived at it in our case too. We need to log "steps" within a single test for automating a formal validation process (medical device industry), and it's easier to have a stateful

cy.testStep

command and some

{before,after}Each

hooks to flush that state to the report file on disk than to have the test author juggle the underlying report data at all. I don't recall offhand though when/if any global variable state in a command file is re-loaded by the Cypress runtime. Gotta be careful not to leak across tests.

That's one win for aliases vs globals; Cypress expects them and you know they are cleared out with each test. Plus you get to see them in the test log.

Yeah though you're kinda SOL with your linter / TypeScript if you use aliases that way

True 😄

Tradeoffs

Yes, and if you don't "initialize" an alias, then attempt to reference it, you'll have problems.

As soon as "check if" makes it into Cypress, probably a good idea to go a different route most of the time

One day maybe I'll rearchitect and remove these, but for now this is in our

e2e.js

, in a

beforeEach()

😄

thanks both for sharing experience. As you mentioned, we also have specific case where we need to store the state before the test and return it after. My service doesn't have control of other service DBs and not to many services are dockerized.