-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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: UNIFY-1310 add tests to runner #20873
Conversation
Thanks for taking the time to open a PR!
|
Test summaryRun details
View run in Cypress Dashboard ➡️ This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
try { | ||
await ctx.actions.project.setProjectIdInConfigFile(args.projectId) | ||
} catch { | ||
// ignore error as not useful for end user to see | ||
} | ||
await ctx.actions.project.setProjectIdInConfigFile(args.projectId) |
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 ignored error was painful for me to track down. I think there's value in having it:
Even if it's not immediately useful for the end user to see, it becomes very useful if/when the end user reports a bug. Without this error, the "Create project" button just fails silently.
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.
hmmm is a way to catch this and provide an useful error message to the end-user so the error isn't hidden while giving the user information on where to find help or how to solve 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.
We end up showing two different errors different places, one of which is the launchpad, which does not seem ideal. @tgriesser is this expected? I only found this error when I went looking for the little blue toast to restart Cypress.
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.
I made https://cypress-io.atlassian.net/browse/UNIFY-1530 to track the error question, I do think it's better not to catch here so that this error goes somewhere, even if the launchpad is not the right place.
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.
Yeah, we probably need to sync on this and figure out how to make this actionable as part of the response of the mutation, rather than having this be unhandled and displayed like this.
Any error in a mutation should be caught/handled, otherwise it shows up as the "An unexpected internal error occurred" as above, which we don't really want. Maybe we want to log the error out to the console or something?
I think the way the error case handled is a bit hard to follow in this flow and could be improved, it's almost like we want the return type of the mutation to be a union of Query | ErrorWrapper
if (newProject.value && pickedOrganization.value) { | ||
const isNewProject = Boolean(newProject.value && pickedOrganization.value) | ||
|
||
if (isNewProject) { |
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.
Just threw in an intermediate variable for clarity
cy.withCtx(async (ctx) => { | ||
const config = await ctx.project.getConfig() | ||
|
||
expect(config.projectId).to.not.equal('newProjectId') |
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.
would this value be undefined?
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.
At this point it's null
. I checked to.not.equal('newProjectId')
instead of to.equal(null)
so that if at some poit in the future a projectId is added to the scaffolded project, this test won't break 😃 happy to change if you prefer
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.
so that if at some point in the future a projectId is added to the scaffolded project
I'm not as familiar with the dashboard space, but if a new scaffolded project had a projectId, are users able to create a new project & override it from the 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.
if a new scaffolded project had a projectId, are users able to create a new project & override it from the UI
I believe so
@@ -171,6 +171,44 @@ describe('App: Runs', { viewportWidth: 1200 }, () => { | |||
}) | |||
}) | |||
|
|||
context('Runs - Create Project', () => { |
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.
Not specific to your changes, but with name of this test file I wasn't expecting these tests to be specific to the dashboard.
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.
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.
We should probably retire the "cypress-in-cypress" convention, it refers to solving a specific problem, which was getting the spec runner to work in Cypress tests.
I do think "runs" is an OK name, since the the app contexts, runs and the "runs page" are all about test runs recorded to the dashboard. But runs_page
is probably clearer file name if we want one, to be more clear that this is checking the display of runs info from the cloud, not anything at all about the behavior of the runner.
I even got confused writing that so we probably do need a better name.
Not that there are getting to be more files in here, it might be a good time to step back and organize this folder with more of pattern... some files test pages, some test multi-page features like the top-nav, and the names of the cypress-in-cypress tests are quite unclear.
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.
I do think "runs" is an OK name, since the the app contexts, runs and the "runs page" are all about test runs recorded to the dashboard.
Given I haven't worked in the dashboard, I alway associate runs to a spec run or test run within a spec. Def an overloaded term.!
I do agree cypress-in-cypress solved a problem that doesn't necessarily need called out.
|
||
cy.visitApp('/runs') | ||
cy.findByText(defaultMessages.runs.errors.unauthorized.button).click() | ||
cy.findByText(defaultMessages.runs.errors.unauthorizedRequested.button).should('exist') |
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.
Just curious, this the context of this test, but is the following describe block of 'Runs - Unauthorized Project Requested'
testing something different compared to the current describe block of Runs - Unauthorized Project
? Wondering if we just need to enhance one of these? If not, what am I missing?
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.
AFAIK in 'Runs - Unauthorized Project Requested'
, we're validating the correct UI appears for users who have previously requested access, whereas in Runs - Unauthorized Project
, we're testing the request access flow itself
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.
Provokes a lot of thoughts about the code around the PR, but the changes look good and it adds the test specified in the ticket. Happy to approve again if you make more changes.
try { | ||
await ctx.actions.project.setProjectIdInConfigFile(args.projectId) | ||
} catch { | ||
// ignore error as not useful for end user to see | ||
} | ||
await ctx.actions.project.setProjectIdInConfigFile(args.projectId) |
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.
I made https://cypress-io.atlassian.net/browse/UNIFY-1530 to track the error question, I do think it's better not to catch here so that this error goes somewhere, even if the launchpad is not the right place.
User facing changelog
n/a
Additional details
projectId
is inserted into config file when a new project is createdHow has the user experience changed?
n/a
PR Tasks
cypress-documentation
?type definitions
?cypress.schema.json
?