-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
cdb-angular(front): Add UI tests #6895
cdb-angular(front): Add UI tests #6895
Conversation
f8ccc82
to
12d5b4d
Compare
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.
@orfeas-k Thanks for the PR. Please take a look at my comments, most of them are trivial.
run: | | ||
cd components/centraldashboard-angular/frontend | ||
npm i | ||
npm run serve & npx wait-on http://localhost:4200 |
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 don't think we need to use npx
since the wait-on
is installed as a dependency.
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.
@tasos-ale I removed it during my fixups but I think after all we need it. The UI tests workflow failed with the following error message:
/home/runner/work/_temp/f28aed23-effd-4194-ab41-bea8ffef080d.sh: line 3: wait-on: command not found
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, let's keep the npx
. I also found an issue for that jeffbski/wait-on#86.
const href = window.location.origin + url; | ||
const urlObject = new URL(href); |
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 can make that change in case url
does not start with /
.
const href = window.location.origin + url; | |
const urlObject = new URL(href); | |
const urlObject = new URL(url, window.location.origin); |
run: | | ||
cd components/centraldashboard-angular/frontend | ||
npm i | ||
npm run serve & npx wait-on http://localhost:4200 |
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 don't think we need npx
since we have wait-on
in our node modules.
if (!firstUrl && !secondUrl) { | ||
console.warn(`Got undefined URLs ${firstUrl} and ${secondUrl}`); | ||
return 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.
This is not this PR, but maybe we want to think if we want to consider undefined
URLs as equals.
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.
Normally, we don't stumble upon 2 undefined URLs (we did with a previous implementation of URLs syncing). Thus, I think we can go ahead and remove this if
completely @tasos-ale
cy.get('iframe', { log: false }) | ||
.its('0.contentWindow.location', { log: false }) | ||
.then(iframeLocation => { | ||
let iframeUrl: string = iframeLocation.pathname + iframeLocation.search; |
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 iframeUrl: string = iframeLocation.pathname + iframeLocation.search; | |
const iframeUrl: string = iframeLocation.pathname + iframeLocation.search; |
|
||
let iframeUrl: string; | ||
|
||
cy.getIframeUrl().then(url => { | ||
iframeUrl = url; | ||
cy.location({ log: false }).should(browserLocation => { | ||
let browserUrl = browserLocation.pathname + browserLocation.search; | ||
browserUrl = removePrefixFrom(browserUrl); | ||
|
||
expect(equalUrlPaths(browserUrl, iframeUrl)).to.be.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.
let iframeUrl: string; | |
cy.getIframeUrl().then(url => { | |
iframeUrl = url; | |
cy.location({ log: false }).should(browserLocation => { | |
let browserUrl = browserLocation.pathname + browserLocation.search; | |
browserUrl = removePrefixFrom(browserUrl); | |
expect(equalUrlPaths(browserUrl, iframeUrl)).to.be.true; | |
cy.getIframeUrl().then(url => { | |
cy.location({ log: false }).should(browserLocation => { | |
let browserUrl = browserLocation.pathname + browserLocation.search; | |
browserUrl = removePrefixFrom(browserUrl);\ | |
expect(equalUrlPaths(browserUrl, url)).to.be.true; |
cy.equalUrls(); | ||
}); | ||
|
||
it('checks the URLs when user clicks and affects the query parameters of the current URL', () => { |
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('checks the URLs when user clicks and affects the query parameters of the current URL', () => { | |
it('checks the URLs when the user triggers an update in query parameters of the current URL', () => { |
cy.equalUrls(); | ||
}); | ||
|
||
it('checks the URLs when user navigates to the corresponding PVC from JWA details page', () => { |
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('checks the URLs when user navigates to the corresponding PVC from JWA details page', () => { | |
it('checks the URLs when the user navigates to the corresponding PVC from JWA details page', () => { |
cy.mockPodDefaultsRequest(); | ||
}); | ||
|
||
it('checks the URLs when user navigates to pages inside the same WA', () => { |
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('checks the URLs when user navigates to pages inside the same WA', () => { | |
it('checks the URLs when the user navigates to pages inside the same WA', () => { |
return this.window.location !== this.parent.location; | ||
return this.window?.location !== this.parent?.location; |
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.
After some digging I found that the reason this.parent.location
is undefined is because Cypress changed it to this.self.location
. If we change the modifyObstructiveCode configuration to false
then we can remove the optional chaining. @orfeas-k wdyt?
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.
Great find! Sounds like a much better solution than introducing optional chaining in a place we normally don't need just for the tests to pass. I 'll push some fix-ups with this included.
- Install Cypress & npm scripts for UI tests - Update frontend README.md with UI tests instructions Signed-off-by: Orfeas Kourkakis <orfeas@arrikto.com>
12d5b4d
to
ef41add
Compare
Pushed fixups with all the comments included @tasos-ale, thanks for taking a look! I had to force push since I removed the commit with the optional chaining. |
Add UI tests with Cypress to check that the URLs of the browser and the iframe are always synced. More specifically, we test the following scenarios: - User navigates to pages inside the same WA (JWA) - User navigates to another WA from the one they were previously in (to the corresponding PVC from JWA details page) - User clicks and affects the query parameters of the current URL (navigates to tabs inside JWA details page) Signed-off-by: Orfeas Kourkakis <orfeas@arrikto.com>
Modify script names in order to conform with script names in other WAs. Signed-off-by: Orfeas Kourkakis <orfeas@arrikto.com>
Signed-off-by: Orfeas Kourkakis <orfeas@arrikto.com>
ef41add
to
38bac7f
Compare
cc @kimwnasptd since this PR needs approval from KF |
@tasos-ale thanks for the review! /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kimwnasptd, tasos-ale The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This PR is part of the CentralDashboard Rewrite effort and adds UI tests with Cypress for the CentralDashboard-angular component. The tests are about functionalities introduced in the sync browser and iframe URLs PR.
Test case scenarios
In all of the above, we need to make sure that the browser's URL always corresponds to the page the user currently views.
Some details on the implementation:
Selecting other WAs' DOM elements
Best practice in Cypress https://docs.cypress.io/guides/references/best-practices#How-It-Works is to add
data-cy-*
attributes to the DOM elements one is trying to use in tests in order to be sure tests don't break unless someone explicitly modifies these attributes. In order to avoid, though, modifying elements in other WAs just to be selectable during the CentralDashboard UI tests, we decided to go with second best practicecy.contains('text content')
, even if it's a more fragile approach thandata-cy-*
attributes.Running UI tests in a GH action
In order to write UI tests for the CentralDashboard that will be able to run in GH actions (since we want any test we write to run also on every PR), we will need to spin up a KinD cluster where we will apply all the necessary manifests, so we can use these WAs to test CentralDashboard's functionalities. Thus, this PR goes ahead and makes use of the testing environment introduced in this PR by @kimwnasptd.