diagnostics - Cypress.env is not a function when referring to env object as const #1120
Comments
jessica-jorgenson
changed the title
That'd be nice, but it's not quite the case. The steps are evaluated in a non-cypress environment and these variables aren't available. This is a result of careful consideration between evaluation and static analysis. For now, you need to move invocation of Cypress function inside methods and away from global scope. I will update the documentation to further explain this, in time. |
|
Thank you! |
|
I found that I previously actually did make attempts at mocking Cypress global during evaluation. Thus, I've improved that behavior slightly with v19.1.1 and your original code should now hopefully run fine. |
|
Oh thank you for working on this! It's definitely a step in the right direction, but it seems it's still having a hard time with the new update. Is it something else I'm doing wrong? |
|
Ah, the return value of mocked functions is just undefined, which means that accessing the value as an object isn't going to work. Doing something about this is out of scope for this project as of now. |
|
I also have this problem. It would be awesome if this was fixed! Is it possible to run the diagnostics script within a Cypress environment so that it doesn't need to be mocked? Maybe the diagnostics code could be ran as a Cypress test? I'd really like to use this tool without needing to change my code. |
This is not something I'm considering right now. I am however open to introducing static analysis with fallback, ref. #1129. |
This is "more proper" in the sense that it's still executing tests an actual Cypress environments, while still being reasonably quick. Having a postinstall not run upon installation turned out to be less trivial than I had hoped for, however SO came to the rescue [1]. This is related to #1120 [2]. This closes #1129 [3]. [1] https://stackoverflow.com/q/54212147/4098802 [2] #1120 [3] #1129
This is "more proper" in the sense that it's still executing tests an actual Cypress environments, while still being reasonably quick. Having a postinstall not run upon installation turned out to be less trivial than I had hoped for, however SO came to the rescue [1]. This is related to #1120 [2]. This closes #1129 [3]. [1] https://stackoverflow.com/q/54212147/4098802 [2] #1120 [3] #1129
This is "more proper" in the sense that it's still executing tests an actual Cypress environments, while still being reasonably quick. Having a postinstall not run upon installation turned out to be less trivial than I had hoped for, however SO came to the rescue [1]. This is related to #1120 [2]. This closes #1129 [3]. [1] https://stackoverflow.com/q/54212147/4098802 [2] #1120 [3] #1129
This is "more proper" in the sense that it's still executing tests an actual Cypress environments, while still being reasonably quick. Having a postinstall not run upon installation turned out to be less trivial than I had hoped for, however SO came to the rescue [1]. This is related to #1120 [2]. This closes #1129 [3]. [1] https://stackoverflow.com/q/54212147/4098802 [2] #1120 [3] #1129
This is "more proper" in the sense that it's still executing tests an actual Cypress environments, while still being reasonably quick. Having a postinstall not run upon installation turned out to be less trivial than I had hoped for, however SO came to the rescue [1]. This is related to #1120 [2]. This closes #1129 [3]. [1] https://stackoverflow.com/q/54212147/4098802 [2] #1120 [3] #1129
This is "more proper" in the sense that it's still executing tests an actual Cypress environments, while still being reasonably quick. Having a postinstall not run upon installation turned out to be less trivial than I had hoped for, however SO came to the rescue [1]. This is related to #1120 [2]. This closes #1129 [3]. [1] https://stackoverflow.com/q/54212147/4098802 [2] #1120 [3] #1129
This is "more proper" in the sense that it's still executing tests an actual Cypress environments, while still being reasonably quick. Having a postinstall not run upon installation turned out to be less trivial than I had hoped for, however SO came to the rescue [1]. This is related to #1120 [2]. This closes #1129 [3]. [1] https://stackoverflow.com/q/54212147/4098802 [2] #1120 [3] #1129
|
Dry run has been completely overhauled with v21.0.0 and changed in regards to the original issue. |
Current behavior
Upon running
npx cypress-cucumber-diagnostics, I am met with the error:When I have a constant equal to a Cypress.env value.
See here: https://github.com/jessica-jorgenson/cucumber-preprocessor-error/blob/main/cypress/support/appOne/pages.ts
When referring to the env like so:
return Cypress.env("urls").main.replace("bing", "google"), the error doesn't occur.Desired behavior
Cypress behaves as usual, so this shouldn't raise an error on cypress-cucumber-preprocessor...riiight?
Test code to reproduce
Repo: https://github.com/jessica-jorgenson/cucumber-preprocessor-error
Versions
Checklist
[email protected](package name has changed and it is no longer the most recent version, see #689).The text was updated successfully, but these errors were encountered: