cy.session: Caching across spec files

What would you like?

The new cy.session is amazing and just what we wanted - the behaviour with cypress open where this feature caches across spec files is something we’d like to have as an option for cypress run as well if possible.

Why is this needed?

In many cases authentication sessions are reliably the same between spec files, and starting with a blank cy.session cache for each file isn’t necessary. I understand that the reason may be more technical, since the runner may be opening each spec file in a brand new context where it’s hard to carry session data around.

Other

Just further thanks for cy.session! 🎉

[romankhomitskyi]

@romankhomitskyi You’ll probably addressing this question at the Cypress team, but I’d like to answer as someone who’s excited about this development. It brings local storage and cookies in line with the Cypress principle of setting up state before each test. This ensures greater test isolation for less flake. Plus, it’s already an optional flag so if you don’t like it you can just not enable. However, it doesn’t make sense to cache cookies if you’re not clearing them.

I am just wondering what kind of flake could be in my flow, where I created bunch of it() to check only one page, and after first it() I get logged out As it was said before, most of the time you do not want to clear local storage There might be a flake in cy.session down the road, that might not be fixed asap, so we can’t rely on it(

[DanJFletcher]

I wish Cypress handled this too. There’s a couple of options to roll this yourself in a way that works in parallel too.

Ultimately you need a file that can be used to persist session data across spec files. With a cypress task you can read/write to files from within a node process.

In my case I made a credentials.json file with the structure:

{
  "<email + password>": {<session data>}
}

Where email and password is concatenated to make a unique key and the value is the session data I need.

You can use this data to restore any required state in localstorage or use it as a way to mock the login request. I updated my login command to behave similar to cy.session in that it does a real login if there’s no cached session but if there is a session, it restores that instead.

It also saves the session to the credentials.json file after a successful login attempt (creates it if it doesn’t exist already).

This works across multiple spec files while still working if they run in parallel. The caveat is that each runner will maintain its own credentials.json file but I don’t personally think that’s a big deal. If you thought it was a big deal you’d have to write to a central cache that all your runners have access to.