Skip to content
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

Merged
merged 20 commits into from
Apr 6, 2022

Conversation

rachelruderman
Copy link
Contributor

@rachelruderman rachelruderman commented Mar 31, 2022

User facing changelog

n/a

Additional details

  1. Adds test to verify that text changes when the Request Access button is clicked
  2. Adds test to verify projectId is inserted into config file when a new project is created
  3. Removes try/catch that was silencing an error message

How has the user experience changed?

n/a

PR Tasks

  • Have tests been added/updated?
  • [na] Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
  • [na] Has a PR for user-facing changes been opened in cypress-documentation?
  • [na] Have API changes been updated in the type definitions?
  • [na] Have new configuration options been added to the cypress.schema.json?

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Mar 31, 2022

Thanks for taking the time to open a PR!

@CLAassistant
Copy link

CLAassistant commented Mar 31, 2022

CLA assistant check
All committers have signed the CLA.

@cypress
Copy link

cypress bot commented Apr 1, 2022



Test summary

17812 0 217 0Flakiness 0


Run details

Project cypress
Status Passed
Commit 1da8e0e
Started Apr 6, 2022 7:10 PM
Ended Apr 6, 2022 7:22 PM
Duration 12:18 💡
OS Linux Debian - 10.10
Browser Multiple

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

@rachelruderman rachelruderman changed the title add test for create project test: UNIFY-1310 validate text after clicking request access button Apr 1, 2022
@rachelruderman rachelruderman marked this pull request as ready for review April 1, 2022 19:43
@rachelruderman rachelruderman marked this pull request as draft April 1, 2022 19:44
@rachelruderman rachelruderman changed the title test: UNIFY-1310 validate text after clicking request access button test: UNIFY-1310 add tests to runner Apr 1, 2022
@rachelruderman rachelruderman marked this pull request as ready for review April 4, 2022 05:58
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)
Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor

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.

Screen Shot 2022-04-05 at 4 19 01 PM

Screen Shot 2022-04-05 at 4 17 06 PM

Copy link
Contributor

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.

Copy link
Member

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

Comment on lines -272 to +274
if (newProject.value && pickedOrganization.value) {
const isNewProject = Boolean(newProject.value && pickedOrganization.value)

if (isNewProject) {
Copy link
Contributor Author

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')
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

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?

Copy link
Contributor Author

@rachelruderman rachelruderman Apr 6, 2022

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', () => {
Copy link
Member

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.

Copy link
Contributor Author

@rachelruderman rachelruderman Apr 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that some of the specs in this directory have the cypress-in-cypress prefix, i.e. cypress-in-cypress-run-mode.cy.ts. Should I update to something like cypress-in-cypress-open-mode-runs.cy.ts or more simply dashboard-runs.cy.ts?

Screen Shot 2022-04-04 at 9 30 19 AM

Copy link
Contributor

@marktnoonan marktnoonan Apr 5, 2022

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.

Copy link
Member

@emilyrohrbough emilyrohrbough Apr 5, 2022

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.

@flotwig flotwig requested a review from emilyrohrbough April 5, 2022 15:35

cy.visitApp('/runs')
cy.findByText(defaultMessages.runs.errors.unauthorized.button).click()
cy.findByText(defaultMessages.runs.errors.unauthorizedRequested.button).should('exist')
Copy link
Member

@emilyrohrbough emilyrohrbough Apr 5, 2022

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?

Copy link
Contributor Author

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

Copy link
Contributor

@marktnoonan marktnoonan left a 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)
Copy link
Contributor

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.

@rachelruderman rachelruderman merged commit 1ef7ffb into 10.0-release Apr 6, 2022
@rachelruderman rachelruderman deleted the unify-1310-run-management branch April 6, 2022 20:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants