-
Notifications
You must be signed in to change notification settings - Fork 15
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
Activity Log settings e2e #2753
Conversation
2f03212
to
4c09d30
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.
Looks good!
Just a doubt about whether we are doing the same thing in beforeEach
and in each test.
cy.get('@initialRetentionTime').then((text) => | ||
section() | ||
.get('[aria-label="retention-time"]') | ||
.should('have.text', text) |
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.
how does this change from what we do in beforeEach
? Are they both needed?
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.
In the beforeEach
clause we read the initial text, here we ensure the test starts from there.
It's indeed a step that never fails, I mostly added it for completing the test case (start from a value x, get another value y). Should we remove it? I see no harm, I wonder if it can work as a "safety net" for regressions.
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.
No need to remove, just wanted to understand the rationale, and make sure it was not accidentally like that.
@@ -677,4 +677,133 @@ context('Settings page', () => { | |||
}); | |||
}); | |||
}); | |||
|
|||
describe('Activity log', () => { | |||
// Elements must be filtered to match only the ones relate to the Activity Logs. |
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.
interesting approach.
Another way that I find helpful in order to get specific elements and avoid weird css selectors is using custom classes/labels/names (take a look at SUMA Credentials Management
section)
No need to change anything, just wanting to share.
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.
First and foremost, I was experimenting thus I'm not sure my approach is good.
We have to face 2 orders of problems here:
- to select the element in the right section
- to select an element that might have been re-rendered.
Regarding 1, maybe selecting even cypress docs says that selecting by text is not a best practice (https://docs.cypress.io/guides/references/best-practices#Text-Content). Perhaps we can assign a specific class/ID to every section? Quirk: models don't fall under any section 🙃
I'm considering a refactor, though.
About 2, I found no other option than to use helper functions. I wonder if it's a huge burden for performance.
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.
Yes, I like that piece of document. I also find using highly brittle selectors that are subject to change (which is not the case here) a pain 🙈
All good from my side
let's review your comments togheter
124ad3d
to
dc9b268
Compare
dc9b268
to
7080165
Compare
7080165
to
bb74f54
Compare
Description
Provide e2e tests for the Activity log section on the settings page.
This PR includes a refactor to the production code (eace365) that simplifies focusing on elements by segmenting the HTML with
<section>
(no UI change is involved).