-
Notifications
You must be signed in to change notification settings - Fork 3.3k
chore: Address skipped specs in server package #22356
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
Conversation
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 |
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 workflow is covered by a system test system-tests/test/network_error_handling_spec.js
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 also have it here for launchpad:
// 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 |
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.
findRemotePort
doesn't exist in firefoxUtil
anymore
}) | ||
|
||
// NOTE: Validated in real use | ||
it.skip('validates cypress.env.json', function () { |
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.
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) => { |
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.
platform
and arch
will be different in CI, so check that they exist but remove them from the config before asserting equality
Test summaryRun details
View run in Cypress Dashboard ➡️ Flakiness
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', () => { |
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 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
now, I would see this error
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.
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`) |
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 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.
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.
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.
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.
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', |
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 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?
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 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 😕
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.
Let's make an issue and add a comment for this then, totally worth investigate.
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.
Added an issue and a comment here
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.
Some comments
defaultValue: (options: Record<string, any> = {}) => options.testingType === 'component' ? defaultSpecPattern.e2e : undefined, | ||
validation: validate.isStringOrArrayOfStrings, | ||
canUpdateDuringTestTime: false, | ||
}, |
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.
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:
cypress/packages/config/src/options.ts
Lines 109 to 112 in 50cc582
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],
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 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 |
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 also have it here for launchpad:
@@ -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' }, |
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.
Why did this get removed?
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). |
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.
Looks good, my changes have been incorporated, or spawned new issues.
…press into 21966-skipped-server-specs
@@ -578,27 +572,27 @@ describe('lib/config', () => { | |||
}) | |||
|
|||
// TODO:(lachlan): after mega PR |
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 TODO has been addressed, should be safe to remove at this point.
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. |
…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)
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
cypress-documentation
?type definitions
?