cypress icon indicating copy to clipboard operation
cypress copied to clipboard

Cypress.env has changed behavior in v10 without any mention in the docs / changelog

Open bahmutov opened this issue 2 years ago • 3 comments

Current behavior

it('first', () => {
  console.log('first test %o', Cypress.env())
  Cypress.env('name', 'Joe')
})

it('second', () => {
  console.log('second test %o', Cypress.env())
})

In Cypress v9 the first test run (using cypress open) The first run Screen Shot 2022-07-27 at 16 01 51

The second run (while the test runner stays open using "R") Screen Shot 2022-07-27 at 16 02 05

The Cypress.env object keeps the changed / updated object.

The same test in Cypress v10 The first run:

Screen Shot 2022-07-27 at 16 05 54

The second run (using "R") Screen Shot 2022-07-27 at 16 06 08

So the Cypress.env object is reset before running the spec, even if the test runner stays open, which is a huge change from v9, and I don't think it was mentioned anywhere in the docs.

Desired behavior

I would love the old behavior, or at least some way to preserve values between the spec runs. Right now using the plugins process via cy.task or something seems to be the only solution to keep the data around

Test code to reproduce

The tests shown

Cypress Version

10.3.1

Other

No response

bahmutov avatar Jul 27 '22 20:07 bahmutov

I worked around it by creating https://github.com/bahmutov/cypress-plugin-config which stores the values on window.top (with Cypress.env fallback). You can see it in action in https://github.com/bahmutov/cypress-slow-down plugin

bahmutov avatar Jul 27 '22 22:07 bahmutov

@bahmutov thank you for logging this. I wasn't aware that Cypress.env had this behavior pre-10.x. I did a little digging in the code, seems like this has been a discussion point before:

https://github.com/cypress-io/cypress/blob/f0ae283b9278ee36c11fcc761a424800035baf5f/packages/driver/src/cypress.ts#L212-L213

And like you said, this change wasn't documented, but the current env documentation doesn't seem to regard either behavior as expected or valid. Personally, it feels odd that we would persist the env between soft re-runs and potentially introduce indeterminant tests, as your example shows.

Your plugin seems like a reasonable middle-ground, though. Am I correct in that your plugin is most impacted by this change with its Change from Command-Line API? Or are there other impacts I'm not seeing?

tbiethman avatar Aug 02 '22 17:08 tbiethman

Yeah it is just unexpected and might affect plugins that cache some data during the first run

Sent from my iPhone

On Aug 2, 2022, at 13:35, Tyler Biethman @.***> wrote:

 @bahmutov thank you for logging this. I wasn't aware that Cypress.env had this behavior pre-10.x. I did a little digging in the code, seems like this has been a discussion point before:

https://github.com/cypress-io/cypress/blob/f0ae283b9278ee36c11fcc761a424800035baf5f/packages/driver/src/cypress.ts#L212-L213

And like you said, this change wasn't documented, but the current env documentation doesn't seem to regard either behavior as expected or valid. Personally, it feels odd that we would persist the env between soft re-runs and potentially introduce indeterminant tests, as your example shows.

Your plugin seems like a reasonable middle-ground, though. Am I correct in that your plugin is most impacted by this change with its Change from Command-Line API? Or are there other impacts I'm not seeing?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

bahmutov avatar Aug 02 '22 20:08 bahmutov