[#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.
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.
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.
frontend/cypress/tests/codeView/codeView_codeHighlighting.cy.js
Outdated
Show resolved
Hide resolved
|
@reposense/active-developers Please help us with a final review for this PR! |
|
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
rgbvalues instead.I chose to suppress warnings for testing the colors of a commit history of
_colors.scssinstead of using another file because it's ascssfile which is unlikely to be touched, while the other files arejavafiles. 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
untildate 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
untildate 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.