Revive DevTools Cypress tests #61972
Conversation
06a9d02 to
a4e8ac1
Compare
a4e8ac1 to
d933250
Compare
Previously these tests would run automatically when Angular DevTools lived in another repo. These files have continued to live here but have not been running automatically on each PR. Now, these test files have been revived to run properly with our changes since the repo merge. This is a first step to reviving our e2e testing. Next steps include writing cypress tests for new features like Injector Graph, Router tree, signals visualizations, etc.
d933250 to
53fccbb
Compare
| uses: cypress-io/github-action@6c143abc292aa835d827652c2ea025d098311070 # v6.10.1 | ||
| with: | ||
| command: cypress run --project ./devtools/cypress | ||
| start: yarn bazel run //devtools/src:devserver |
There was a problem hiding this comment.
Nit: Can we pass through the port here so we don't rely on a default which might change? ex. yarn bazel run //devtools/src:devserver -- --port 4200?
| @@ -23,15 +21,15 @@ describe('Testing the Todo app Demo', () => { | |||
| }); | |||
|
|
|||
| it('should contain the "Components" tab', () => { | |||
| cy.contains('.mat-tab-links', 'Components'); | |||
| cy.contains('.devtools-nav', 'Components'); | |||
There was a problem hiding this comment.
Follow up: Since this is just reviving this existing tests, I'm all for doing the minimum amount of work to get things working.
As we move forward, we should consider the design of assertions in e2e tests. At Google, the testing teams typically recommend imaging e2e tests like a real end user driving your application or as if you're writing a script for a real human to follow, often using text and the a11y tree to denote specific elements.
So this test might be better expressed as looking for the label "Components" inside of a button / [role="button"], since that's what the user / screen reader would be looking for. It makes these tests much less brittle to internal changes like class or ID names.
I'm not sure what patterns work best for Cypress in particular (our internal tooling is designed to support this methodology), so there might be some trial and error needed here to figure out what works best.
Again, not a blocker for this PR given we're enabling existing tests, but just something to think about as we move forward from here.
| describe('Testing the Todo app Demo', () => { | ||
| beforeEach(() => { | ||
| cy.visit('/'); | ||
| }); | ||
|
|
||
| it('should contain the todos application', () => { | ||
| cy.enter('#sample-app').then((getBody) => { | ||
| cy.enterIframe('#sample-app').then((getBody) => { |
There was a problem hiding this comment.
Comment: NGL, it looks really sketchy to me to have a bunch of dangling .then calls like this. It looks like a dropped Promise. The it looks normal too, but presumably is Cypress-aware and knows to wait on these operations?
This seems the way Cypress tests are supposed to be written, so I don't think it's anything wrong this PR, just an observation its design.
| // | ||
| // -- This will overwrite an existing command -- | ||
| // Cypress.Commands.overwrite("visit", (originalFn, url, options) => { ... }) | ||
| export function enterIframe(selector) { |
There was a problem hiding this comment.
Nit: I think we can drop export here?
| // | ||
| // -- This will overwrite an existing command -- | ||
| // Cypress.Commands.overwrite("visit", (originalFn, url, options) => { ... }) | ||
| export function enterIframe(selector) { |
There was a problem hiding this comment.
Consider: Some doc comment explaining what this command does and its expected inputs/outputs would be helpful for future readers.
| // structual directive example | ||
| @Directive({ | ||
| selector: '[appStructural]', | ||
| standalone: true, |
There was a problem hiding this comment.
Nit: We don't need standalone: true in v20, it's the default.
| }); | ||
| } | ||
|
|
||
| Cypress.Commands.add('enterIframe', enterIframe); |
There was a problem hiding this comment.
Follow up: It was only at this point that I realized these tests are all written in JS (otherwise how does it type check cy.enterIframe?). Maybe a good next step after this PR would be to see if we can update them to TypeScript?
Previously these tests would run automatically when Angular DevTools lived in another repo. These files have continued to live here but have not been running automatically on each PR.
Now, these test files have been revived to run properly with our changes since the repo merge. This is a first step to reviving our e2e testing.
Next steps include writing cypress tests for new features like Injector Graph, Router tree, signals visualizations, etc.
https://github.com/angular/angular/actions/runs/15668389113/job/44135544662?pr=61972#step:9:583