-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: tweak simulated run mode and some other tests for flake #25623
Conversation
@@ -92,13 +84,3 @@ describe('Cypress In Cypress - run mode', { viewportWidth: 1200 }, () => { | |||
cy.findByTestId('sidebar').should('not.exist') | |||
}) | |||
}) | |||
|
|||
function simulateRunModeInUI () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This always felt hacky, it was OK prior to Dec 2, 2022, but the new approach is a lot more stable than modifying the window since the value will be there before the app initializes at all.
@@ -32,6 +32,7 @@ | |||
<img | |||
v-if="selectedBrowser.displayName" | |||
class="min-w-16px w-16px" | |||
alt="" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might as well treat this image as decorative and hide it from screen readers, the text is right next to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The empty alt text will mark it as decorative, but if we want to hide it from readers wouldn't we need something like aria-hidden="true"
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They have the same effect (as would role="presentation"
), empty alt
is just more standard for various reasons. It predates all the aria stuff.
@@ -35,7 +35,7 @@ | |||
@panel-width-updated="handlePanelWidthUpdated" | |||
> | |||
<template #panel1="{isDragging}"> | |||
<HideDuringScreenshotOrRunMode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is changed since we already know for sure it is open mode, the run mode scenario doesn't exist.
* Helper to reset focus for tooltips | ||
* jQuery .blur() seemed unreliable, leading to flake | ||
*/ | ||
function clickAway () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to understand more how this fixes the problem better than just the blur
does. If this is the best way to handle tooltip dismissals, then perhaps the concept could be encapsulated in a custom cy
command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the intent is to ensure all tooltips are closed and lose focus there is a special function provided by our chosen tooltip library that allows you to close all open instances - would introduce tighter coupling to the impl but we're already using it in our StandardModal.vue
🤷♂️
import { hideAllPoppers } from 'floating-vue'
...
hideAllPoppers()
Just floating as a possibility, probably overkill for this scenario
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A custom command would make sense in tackling this more broadly.
I can think of a few ways to tease out what is going on, maybe by displaying the mouse position or something, but that's probably a separate task.
@@ -32,6 +32,7 @@ | |||
<img | |||
v-if="selectedBrowser.displayName" | |||
class="min-w-16px w-16px" | |||
alt="" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The empty alt text will mark it as decorative, but if we want to hide it from readers wouldn't we need something like aria-hidden="true"
?
@@ -1 +1 @@ | |||
export const isRunMode = window.__CYPRESS_MODE__ === 'run' && window.top === window | |||
export const isRunMode = window.location.href.includes('CY_IN_CY_SIMULATE_RUN_MODE') || (window.__CYPRESS_MODE__ === 'run' && window.top === window) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we extract CY_IN_CY_SIMULATE_RUN_MODE
as a constant? Feels like a we're adding in more magic strings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Constant is a good idea, will do.
* Helper to reset focus for tooltips | ||
* jQuery .blur() seemed unreliable, leading to flake | ||
*/ | ||
function clickAway () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the intent is to ensure all tooltips are closed and lose focus there is a special function provided by our chosen tooltip library that allows you to close all open instances - would introduce tighter coupling to the impl but we're already using it in our StandardModal.vue
🤷♂️
import { hideAllPoppers } from 'floating-vue'
...
hideAllPoppers()
Just floating as a possibility, probably overkill for this scenario
export const isRunMode = window.__CYPRESS_MODE__ === 'run' && window.top === window | ||
import { CY_IN_CY_SIMULATE_RUN_MODE } from '@packages/types/src/constants' | ||
|
||
export const isRunMode = window.location.href.includes(CY_IN_CY_SIMULATE_RUN_MODE) || (window.__CYPRESS_MODE__ === 'run' && window.top === window) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be another window variable? We could set something like window.__CYPRESS_CY_IN_CY_SIMULATE_RUN_MODE
. I think the implementation of this would be a bit more involved since you might have to funnel this variable into the serving of the app index.html but the benefit would be that it would fit into the existing strategy. With this we now have state stored on the window and the URL
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initially it was on the window and like you picked up on, Cypress setting it is too late in the process, so I think you're right, we'd have to modify the page itself before it's served, or hook in earlier so that the page renders in run mode.
I think it's OK to use the URL to tell a page to start out in a particular state. It's also kinda neat if you are in actual open mode and want to flip to "simulated run mode".
Opening to revisiting at any time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The toggling between seems cool! Good way to test the run mode vs open mode UI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mayben window:before:load
could have worked, will test that out. But yeah the toggling might actually be easier than running --headed and having to restart Cypress in some situations
Additional details
#24846 changed the way
run
mode is determined, which introduced some flake in thecypress-in-cypress-run-mode
tests which simulatedrun
mode by modifyingwindow.__CYPRESS_MODE__
.The flake wasn't noticed right away, since the tests usually passed with retries, in a pretty accidental way.
This PR cleans up those tests and a few other instances of flake that were noticed along the way, and changes the way
run
mode is simulated in the cy-in-cy test. TheisRunMode
utility function added in #24846 can now return true if a specialCY_IN_CY_SIMULATE_RUN_MODE
parameter is added to the URL. This removed the race condition on startup between Cypress overriding the global variable and the Vue app initializing that I suspect was at the root of the flake.This PR does a few other things as well, let's explain them:
CloudViewerAndProject
andLoginConnectModals
to render always in open mode - since the navbar in open mode now shows some cloud data, and avoiding them in the spec-runner was mostly about avoiding graphql in run mode.window.__CYPRESS_MODE__ !== 'run'
to use theutils/isRunMode
function - this makes things more consistent and makes the cy-in-cy run mode tests behave betterHideDuringScreenshotOrRunMode
component - this was hanging around from the time beforeSpecRunnerOpenMode
andSpecRunnerRunMode
were split up. It was still used inSpecRunnerOpenMode
even though that is never rendered inrun
mode. This had confusing side effects in the simulated run mode.Steps to test
Run the tests in
packages/app/cypress/e2e/cypress-in-cypress-run-mode.cy.ts
locally and make sure they they pass and look correct. Verify we see no flake in CI.Similarly, check
packages/app/src/runner/selector-playground/SelectorPlayground.cy.tsx
and see that it passes locally too.How has the user experience changed?
PR Tasks
cypress-documentation
?type definitions
?