-
Notifications
You must be signed in to change notification settings - Fork 154
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
[#2136] Add Tests for Segment CSS #2137
Conversation
I've also looked at #1613 suggesting snapshot testing, but I have a few concerns. For example, there may be differences between systems that make snapshots unreliable. Here's a sample report from dashboard #2137 (The relevant commit history is taken from Jor, testrepo-Delta): And here's the locally built equivalent: Perhaps this points to a deeper bug, but I've opted to stay away from this solution for now. If anyone has an idea of what's causing or how to fix this, do let me know! |
.parent() // .line-content | ||
.parent() // .code | ||
.should('have.css', 'background-color') | ||
.and('not.eq', 'rgb(255, 255, 255)') // #ffffff |
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 the background color used is always consistently chosen, is it not possible to check for the exact color here instead of checking for not white?
Doing this would make the test case more robust, ensuring the merged group code is highlighted based on author's color and not all just green.
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.
Thanks for pointing that out! I went to look at how the colours are generated (in c-authorship.vue
) and it turns out that the first 10 colours are consistently chosen, while the 11th onward is randomly generated. I'll amend the code since we're only testing the first two colours.
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.
LGTM, thanks for adding these tests!
frontend/cypress/tests/codeView/codeView_codeHighlighting.cy.js
Outdated
Show resolved
Hide resolved
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.
LGTM, thanks for providing context & great job on the comments in the test file describing assumptions & the navigation of parent elements!
@reposense/active-developers Please help us with a final review for this 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.
LGTM!
The following links are for previewing this pull request:
|
Fixes #2136
Proposed commit message
Other information
Hex values cannot be used directly because of Cypress limitations. Since we'll need an external library (Chai) for that, I have opted to use
rgb
values instead.I chose to suppress warnings for testing the colors of a commit history of
_colors.scss
instead of using another file because it's ascss
file which is unlikely to be touched, while the other files arejava
files. This may not be so necessary if the below concern is addressed.Also, it seems that for quite a few tests (including the ones these are derived from), the
until
date is set to the current date, which can produce regressions like #2111. Additionally, for certain types of tests (like the ones which group a repo's entire commit history), certain assumptions (like the latest author for a line of code) can be broken which may cause the test to break.The most convenient solution would be to set the
until
date for relevant tests to a fixed date in the past (like 2021), while the generated report for testing could also be anchored to a past date. Perhaps this should be addressed in another PR so we can avoid more nasty surprises.