-
Notifications
You must be signed in to change notification settings - Fork 3.4k
chore(launchpad): work on infra for scaffold tests #20818
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!
|
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 |
||||||||||||||||||||||||||||||||||
| }) | ||
| } | ||
|
|
||
| describe('scaffolding new projects', () => { |
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 need more to express the scaffolded CT cypress.config.js, but since that's changing soon with the CT Arch project, I'll add those when we actually implement the changes.
flotwig
left a comment
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.
very cool!
| // Also defined in lib/fixtures, but we do not want to | ||
| // import from system-tests into code we ship in production. | ||
| const cyTmpDir = path.join(tempDir, 'cy-projects') |
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 are we shipping test code in production? this seems very wrong
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 not super ideal - I will move this into a cy.task.
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.
| const files = ( | ||
| await Promise.all([ | ||
| globby(path.join(this.ctx.currentProject, 'cypress'), { onlyFiles: true }), | ||
| globby(path.join(this.ctx.currentProject, 'cypress.config.*'), { onlyFiles: 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.
globby only works with forward slashes, so this will break for Windows contributors: https://github.com/sindresorhus/globby#api
suggested to do something like https://stackoverflow.com/a/63251716/3474615 to ensure these are POSIX paths
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.
Done. Please see https://github.com/cypress-io/cypress/pull/20818/files#diff-205e537e85adf50907257ece5985a0576754cefa95b0f691cc68bb8c11b7c3d0R98-R118
Shouldn't we just use path.posix.join all the time? Any case to not use 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.
I think we should use the real, native path wherever possible, since it's what most APIs expect, and also what users expect. So backslashes (path.win32.sep) on Windows, forward slashes (path.posix.sep) on Linux/macOS. The only exceptions to this that I know of are globby and when we're codegenning paths for import/require.
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.
Sounds good.
packages/data-context/package.json
Outdated
| "dataloader": "^2.0.0", | ||
| "dayjs": "^1.9.3", | ||
| "dedent": "^0.7.0", | ||
| "disparity": "^3.0.0", |
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 and temp-dir should be in devDependencies since this is test code
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 moved these from data-context to launchpad when moving the test code to a task, and also moved them into devDependencies, so they are no longer in dependencies.
| export class TestActions { | ||
| constructor (private ctx: DataContext) {} | ||
|
|
||
| async #snapshotScaffoldedFiles (expectedScaffoldDir: string, filesToDiff: FileToDiff[]): Promise<SnapshotScaffoldTestResult> { |
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 are these functions named with # at the start? I haven't seen this before, and a cursory search suggests it may come from ruby or java?
If it's to denote these functions as internal, then I'd rather use an _, which I've seen in JS before, or even better, don't define them on the class at all. Could put them up above, since they don't use this at all.
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's a new shortcut for doing private methodName() {... I had to look it up too. Honestly I prefer private just because it's more visually distinct, but absent of a coding styleguide to back me up, I was gonna keep it to myself 😄
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 think JS lends itself poorly to OOP / classes, and the less of it we do the better our code is going to come out. :P
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.
Sure, we can just use private. My reasoning here was it makes more sense to use a native JS feature, which has runtime privacy guarantees, instead of a compile time only, proprietary TS feature where possible, but I don't think it makes too big a difference either way.
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 ended up moving everything into a task: https://github.com/cypress-io/cypress/pull/20818/files#diff-205e537e85adf50907257ece5985a0576754cefa95b0f691cc68bb8c11b7c3d0 which is just a function, no class, so this problem is gone.
I do think it's better to use native JS runtime features where we can over TS compile time features, though, but we can discuss that at some point; this PR no longer uses either.
| @@ -0,0 +1,11 @@ | |||
| import { defineConfig } from '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.
So this is unrelated to the PR, but I think it would be a good idea to have a comment about what defineConfig actually does and why people should use it. As far as I understand it, its only job is to provide typing information, and is recommended but not required?
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 have a lot of comments in the other generated files, and it feels strange that the most important one doesn't explain what's going on in here at all.
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.
Yep, it's just for type interface - it's a no-op.
It might be good to explain what this does with a comment in the generated code, but changing the actual content of the scaffolded files needs to go through DX and friends. Luckily, if we do, it's trivial to update these tests with the infrastructure introduced here.
Let's follow up with DX internally.
|
@BlueWinds @flotwig I addressed all the feedback, summary:
Can you please re-review? Thanks! Edit: CI is having some problems (we discussed internally). Let's wait until it's green, then 👀 and ✅. |
|
Ok, it's green again! 🙏 |
ZachJW34
left a comment
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 great! Could this system be used for some of the existing system-test projects we have like vue-cli-{configured,unconfigured}? Had a few minor comments but going to approve.
| import { cyTmpDir } from '@tooling/system-tests/lib/fixtures' | ||
|
|
||
| const systemTestsDir = path.join(__dirname, '..', '..', '..', '..', 'system-tests', 'projects') | ||
| const systemTestsDir = path.posix.join(__dirname, '..', '..', '..', '..', 'system-tests', 'projects') |
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.
Right, I see - thanks.
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.
Ok, I think I've done this right now. We only use posix for the globby globs now. Can you please double check? Thanks.
|
One more set of 👀 @flotwig 🙏 |
|
Still managed to mess up the path stuff and broke windows. Fixing... #20914 |
* 10.0-release: (92 commits) chore: remove dependency-tree dep (#20905) chore(launchpad): work on infra for scaffold tests (#20818) fix: build mjs in the cli (#20889) fix(unify): Cypress version link should point to Cypress doc's changelog (#20869) fix: windows build (#20854) fix: add index.mjs to the published files of cli (#20884) refactor: lift indexHtmlFile up to component, add validation (#20870) fix: allow migration of pluginsFile using `env` properties (#20770) fix: viewport from CLI on CT (#20849) Don't communicate if process isn't connected Remove config.get Update packages/data-context/src/data/ProjectLifecycleManager.ts fix: git data source unit test failure (#20875) add comment for autoBindDebug fix: Ensuring current browser is synchronized between app and launchpad (#20830) Fix missed await on merge conflict resolution test(unification): move record keys to contexts (#20860) test: move record keys to contexts (#20859) PR comments Fix tests that visit app without a configured testing type ...

User facing changelog
Add some code to assert the correct files are created for new projects. It makes it quickly and easy to add new projects and assert the scaffolded code is what we expect.
Additional details
See this file for more details on my idea: https://github.com/cypress-io/cypress/pull/20818/files#diff-4b0c978082d6a9bf6dd7dfb2211caa0bf93f93a20da215a9907bd3e3c840137f
Basically, I added a function in
TestActionsthat is kind of like snapshots for the scaffolded files. If a project hasn't got any expected files (in thecypress-expecteddirectory) we just copy the scaffolded ones there, like a snapshot, for next time the test runs.If the files do exist, we assert the scaffolded files are the same as the expected ones.
When successful, a test looks like this:
s
A failure shows the diff:
How has the user experience changed?
PR Tasks
cypress-documentation?type definitions?cypress.schema.json?