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

chore: Address skipped specs in server package #22356

Merged
merged 17 commits into from Jun 27, 2022

Conversation

astone123
Copy link
Contributor

@astone123 astone123 commented Jun 16, 2022

User facing changelog

n/a

Additional details

Some test suites were skipped during the unification effort. We need to re-visit those skipped tests and either revise them to cover new workflows, get coverage elsewhere and/or remove them.

I marked the diff with explanations for the changes that I made. Look through the changes and make sure that you agree with what changes were made to the tests.

I revised and/or deleted most single tests that were skipped, but there were some entire test files that were skipped and I think that we should handle those in separate tickets. You can see all of the related tickets organized in this epic

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?

@astone123 astone123 self-assigned this Jun 16, 2022
@cypress-bot
Copy link
Contributor

cypress-bot bot commented Jun 16, 2022

Thanks for taking the time to open a PR!

@@ -1731,26 +1702,6 @@ describe('lib/cypress', () => {
})
})

// NOTE: skipped because we want to ensure this is captured in v10
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 workflow is covered by a system test system-tests/test/network_error_handling_spec.js

Copy link
Contributor

Choose a reason for hiding this comment

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

// TODO: pick open port for debugger
it.skip('finds remote port for firefox debugger', function () {
return firefox.open(this.browser, 'http://', this.options, this.automation).then(() => {
// expect(firefoxUtil.findRemotePort).to.be.called
Copy link
Contributor Author

Choose a reason for hiding this comment

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

findRemotePort doesn't exist in firefoxUtil anymore

})

// NOTE: Validated in real use
it.skip('validates cypress.env.json', function () {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a system test for cypress.env.json validation

@@ -1481,24 +1472,26 @@ describe('lib/config', () => {

return config.mergeDefaults(obj, options)
.then((cfg) => {
['platform', 'arch'].forEach((x) => {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

platform and arch will be different in CI, so check that they exist but remove them from the config before asserting equality

@cypress
Copy link

cypress bot commented Jun 17, 2022



Test summary

37681 0 456 0Flakiness 9


Run details

Project cypress
Status Passed
Commit b6d1df2
Started Jun 24, 2022 4:34 PM
Ended Jun 24, 2022 4:52 PM
Duration 18:47 💡
OS Linux Debian - 10.11
Browser Multiple

View run in Cypress Dashboard ➡️


Flakiness

commands/actions/click.cy.js Flakiness
1 ... > scroll-behavior > can scroll to and click elements in html with scroll-behavior: smooth
commands/xhr.cy.js Flakiness
1 ... > logs request + response headers
2 ... > logs response
cypress/proxy-logging.cy.ts Flakiness
1 Proxy Logging > request logging > xhr log has response body/status code when xhr response is logged first
2 ... > intercept log has consoleProps with intercept info
This comment includes only the first 5 flaky tests. See all 9 flaky tests in the 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

@@ -578,27 +570,27 @@ describe('lib/config', () => {
})

// TODO:(lachlan): after mega PR
context.skip('specPattern', () => {
context('specPattern', () => {
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 want to point out that fixing this test uncovered that we aren't validating the specPattern property in our latest version. This would be an issue if a user had a specPattern in their config that wasn't either a string or an array of strings. For example, if I had

specPattern: 5

in my configuration, I would see this error
Screen Shot 2022-06-17 at 12 27 02 PM

now, I would see this error

Screen Shot 2022-06-17 at 12 25 47 PM

Copy link
Contributor

Choose a reason for hiding this comment

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

Lol, as soon as we skipped a test, the functionality regressed and no-one noticed. Obvious lesson is don't skip tests!!!!! 🤦

const errors = require(`../../../lib/errors`)
const browsers = require(`../../../lib/browsers`)
const { openProject } = require('../../../lib/open_project')
const events = require(`../../../lib/gui/events`)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I deleted this test because the functions exported by the events module don't appear to do anything. The body of each condition of the switch statement is commented out.

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's make a ticket to clean those out, iirc this is stuff @tgriesser kept around for reference purposes during a transition. Doesn't quite make sense to remove them in this PR for sure. But maybe Tim can tell us if it's safe to remove now.

@astone123 astone123 marked this pull request as ready for review June 21, 2022 18:42
@astone123 astone123 requested review from a team as code owners June 21, 2022 18:42
@astone123 astone123 requested review from chrisbreiding and removed request for a team June 21, 2022 18:42
@marktnoonan marktnoonan self-requested a review June 22, 2022 02:33
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.

Some good changes here! Requesting one change in the validation, to include the default specPattern values. I might have one or two other questions tomorrow.

For the tests you mentioned in the description that aren't addressed in this PR, let's make those issues and link them up before merging the PR. It might be good to reach out to @tgriesser and get some notes on what is needed to fix them, or confirm if, say, these unit tests are still needed, given that the comment says this is tested through open mode now.

@@ -419,6 +419,11 @@ const resolvedOptions: Array<ResolvedConfigOption> = [
canUpdateDuringTestTime: false,
requireRestartOnChange: 'server',
},
{
name: 'specPattern',
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a good catch! We seem to also declare the default values in other cases. Looks like we can use the same options.testingType ternary that's being used for viewportWidth etc to populate the defaults that are declared in this file already in the defaultSpecPattern object. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added that but then I just removed it again... I'm confused about what defaultValue does here. It looks like it was messing up some of the validation in the tests when I had it in there 😕

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's make an issue and add a comment for this then, totally worth investigate.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added an issue and a comment here

Copy link
Contributor

@lmiller1990 lmiller1990 left a comment

Choose a reason for hiding this comment

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

Some comments

defaultValue: (options: Record<string, any> = {}) => options.testingType === 'component' ? defaultSpecPattern.e2e : undefined,
validation: validate.isStringOrArrayOfStrings,
canUpdateDuringTestTime: false,
},
Copy link
Contributor

Choose a reason for hiding this comment

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

Am I missing something, this seems the opposite of what we want:

options.testingType === 'component' ? defaultSpecPattern.e2e

If we are using component testing, default to the e2e spec pattern?

I think you want these:

export const defaultSpecPattern = {
e2e: 'cypress/e2e/**/*.cy.{js,jsx,ts,tsx}',
component: '**/*.cy.{js,jsx,ts,tsx}',
}

Maybe it should be

defaultValue: (options: Record<string, any> = {}) =>defaultSpecPattern[options.testingType],

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah that was wrong... I ended up removing the defaultValue because it was causing issues. It seems like options.testingType was undefined sometimes when inside of the defaultValue function. I don't think that we need that property here based on the tests

@@ -1731,26 +1702,6 @@ describe('lib/cypress', () => {
})
})

// NOTE: skipped because we want to ensure this is captured in v10
Copy link
Contributor

Choose a reason for hiding this comment

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

@@ -1525,7 +1518,6 @@ describe('lib/config', () => {
supportFile: { value: false, from: 'config' },
supportFolder: { value: false, from: 'default' },
taskTimeout: { value: 60000, from: 'default' },
specPattern: { value: '**/*.*', from: 'default' },
Copy link
Contributor

Choose a reason for hiding this comment

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

Why did this get removed?

packages/server/test/unit/config_spec.js Outdated Show resolved Hide resolved
@lmiller1990
Copy link
Contributor

As for adding missing coverage, I'd agree we make new tickets for each one (or maybe can group some). Would you like to to that? You could then reference this one in their description.

I think

Are probably the more important ones (and likely can be replaced by a handful of integration tests, instead of 50+ unit tests).

@lmiller1990 lmiller1990 self-requested a review June 24, 2022 00:53
Copy link
Contributor

@lmiller1990 lmiller1990 left a comment

Choose a reason for hiding this comment

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

Looks good, my changes have been incorporated, or spawned new issues.

@@ -578,27 +572,27 @@ describe('lib/config', () => {
})

// TODO:(lachlan): after mega PR
Copy link
Contributor

Choose a reason for hiding this comment

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

The TODO has been addressed, should be safe to remove at this point.

@astone123 astone123 dismissed marktnoonan’s stale review June 24, 2022 14:49

Requesting review again

@lmiller1990
Copy link
Contributor

I do no know what's going on with the failing windows test, but it's happening in multiple branches, and I do not think it was introduced here. I am going to force merge this, then look into the windows CI fail.

@lmiller1990 lmiller1990 merged commit 22d2c31 into develop Jun 27, 2022
@lmiller1990 lmiller1990 deleted the 21966-skipped-server-specs branch June 27, 2022 02:34
tgriesser added a commit that referenced this pull request Jun 27, 2022
…esser/CLOUD-577-spec-list-display-latest-runs-batching

* muaz/CLOUD-577-spec-list-display-latest-runs:
  test: Addressing launchpad test flake in Windows (#22536)
  address comments from @marktnoonan
  Address code review comments
  followup on other comments
  re: @lmiller1990 PR comments
  chore(deps): update dependency semantic-release to v19 [security] (#22238)
  chore: Address skipped specs in server package (#22356)
  Address code review findings
  Address code review findings
  Empty-Commit to generate new percy nonce
  fix: handle case of implicit plugins/index.js files during migration (#22501)
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.

Audit and address spec skips in server package related to unification dev
4 participants