Cypress: Question: Possible to .visit() once, or have multiple describes per visit?

[taitems]

Apologies as this a question, not a bug report.

Is there a way to create a single visit at the beginning of a spec file, and then perform the various describes/contexts/its off of this state. The main goal being the same organised, neatly divided GUI but without the need to load a slow page every single time?

Can this be done by caching a visit and somehow passing it between its?

I have some slower background async methods I have to use a wait a few seconds for. As I currently generate a new visit in the beforeEach for every test, the overall test time grows immensely.

[brian-mann]

You could simply cy.visit in a before instead of beforeEach.

We understand why you'd want to do this (it makes sense) but there are some big draw backs to this, so it's not the recommended / best approach.

Ideally you'd just fix what makes this page load slow - either by doing some general ops work or mocking things, stubbing network requests, taking shortcuts, etc. If it's slow for your tests, it is slow for your users.

While the tests will run faster by by visiting once per feature set, the hidden cost here is that as you iterate and write each test you're paying that performance penalty for every single change you make.

By fixing the root cause you not only increase your productivity when writing tests, but you also don't have to workaround your site being slow and thereby potentially introducing more complexity and state management problems.

[taitems]

@brian-mann Thanks for the prompt reply! I'll look into the before.

The qualifier is that I'm testing an SPA, so while it is an undesirable experience to do the initial load for customers, we do a lot of smart caching and setting contexts within the app. Once they cop that initial slow load, they should be good.

The tests I've written are primarily EUE. Generally I want to some of these tests at desktop size, change viewport, do these tests at mobile size without the need for a reload.

But yes, I totally agree with the architectural argument. It's not entirely within my control, so that's why I was trying to find a short term workaround. Thanks again.