Conversation
line-o
left a comment
There was a problem hiding this comment.
I went through each commit separately as the changesets where so large.
I see that this allows to follow the development of the tests and the tests we end up with are easy to understand and grouped by the pages they are testing.
I would want to discuss if we need to keep the intermediate steps in the git history or if it would be cleaner and also easier to understand in the future to squash the changes into one ore two.
Especially the fact that a lot of files, commands and settings are first created just to be later removed again is why I think the project would benefit from a cleaned up history.
If we want to
- keep the connection from a test case to the previous test case
I would be in favour of a comment in the test file that refs the original web driver test file - keep the history of the approach taken
I would prefer that to be summarised in text form or that we keep this branch and not delete it.
Happy to hear your thoughts on all this. Just to be clear, I think that the tests will make a change for the better as they are much cleaner in both setup and grouping. So I am looking forward to making this switch.
| viewportWidth: 1280, | ||
| viewportHeight: 720, | ||
| trashAssetsBeforeRuns: true, | ||
| includeShadowDom: true, |
There was a problem hiding this comment.
I would be surprised to see shadowDom used in hsg-shell
There was a problem hiding this comment.
Is this setting on by default or because you anticipate we are going to need shadowDom later?
There was a problem hiding this comment.
while i expect shadow dom as part of rewrites, it also ensures that the config between hsg-shell and other jinks profile things stays consistent. The flag adds no performance penalties if no shadow dom is present.
cypress.config.cjs
Outdated
| includeShadowDom: true, | ||
| retries: 1, | ||
| supportFile: 'tests/cypress/support/e2e.js', | ||
| specPattern: 'tests/cypress/e2e/**/*.cy.{js,jsx,ts,tsx}', |
There was a problem hiding this comment.
At the moment we do only have js files, correct?
| @@ -0,0 +1,29 @@ | |||
| const { defineConfig } = require('cypress'); | |||
There was a problem hiding this comment.
I would prefer the configuration to be an ES module
There was a problem hiding this comment.
I would rather change that once cypress and its docs make the switch, otherwise it just creates additional friction for interacting with the tests.
| '&sort-by=relevance', | ||
| '&sort-by=date-asc' | ||
| { | ||
| label: '&sort-by=relevance', |
There was a problem hiding this comment.
I do see the value of using the qs object directly as test input. If the label is and will always be just the serialised quer string I wonder if it could not be serialised within the test function instead.
That way label and qs object cannot deviate from one another in the future.
| const countNum = count.replace(/,/, '') | ||
| console.log('count=', countNum) | ||
| expect(countNum).to.equal('4512', 'Current result did not match expected result') | ||
| cy.visit('search', { |
There was a problem hiding this comment.
I wonder if the approach taken in prod_ser_filter_results - to create tests programmatically can be used in prod_search_new-indexes as well
| cy.getCssProperty('.hsg-breadcrumb__list-item:nth-last-child(2) .hsg-breadcrumb__link:before', '-webkit-mask').then((c) => { | ||
| //console.log('c=', c); | ||
| expect(c).to.equal('url(../images/arrow_back.svg) no-repeat center/contain;') | ||
| cy.get('.hsg-breadcrumb__list-item:nth-last-child(2) .hsg-breadcrumb__link').then(($el) => { |
There was a problem hiding this comment.
Note to self: I hope we can find a more future proof way of ensuring the correct display on smaller screens.
| ### Check currently installed versions | ||
|
|
||
| 1. node: `node -v` => Should output `v18.18.2` | ||
| 1. node: `node -v` => Should satisfy `package.json` engines (e.g. `>=18.0.0`; the asdf example uses 18.18.2). |
There was a problem hiding this comment.
What is the asdf example that is referred to here?
There was a problem hiding this comment.
seection 1.1 from this readme
| ```bash | ||
| npm run cy:run:jenkins | ||
| ``` | ||
| Specs live under `tests/cypress/e2e/` by feature; many areas use subfolders (e.g. conferences by year, countries/archives, departmenthistory/buildings) so each spec can run in parallel: |
There was a problem hiding this comment.
Is it necessary to put test suites that should run in parallel in subfolders?
There was a problem hiding this comment.
it makes for nicer reporting, but is not strictly necessary. I propose to rethink that once we actually expand the tests.
- Add Cypress e2e suite with one spec per page and beforeEach(visit) - Add normalizeHeadlineText custom command; use cy.contains for simple headlines - Group specs in subfolders (e.g. conferences by year, countries/archives) - Add @see comments referencing original tests/specs/**/prod_*.spec.js (wdio) - Add .github/workflows/cypress.yml to run Cypress in Firefox against eXist - Update README and add tests/cypress/COVERAGE_COMPARISON.md - Align search new-indexes assertions (China, Tokyo) with 12eb024 (at least N results)
- Increase body-max-line-length from 200 to 250 - Add footer-max-line-length rule set to 150
This ports the test from the original 24 wdio specs (
npm test) to cypress.none of the old tests or their dependencies have been removed yet, as requested.
It also adds actually executing the tests on CI using the
joewiz/hsg-projectcontainer.note: the e2e test run is not yet taken into account for automated releases, that still works as before.
OP#290