Cypress er treig og vi bør gjøre noe med det 🐌

[wkillerud]

Ser kjøretiden på de visuelle regresjonstestene kryper over et kvarter med jevne mellomrom. Det er kjedelig å vente på, særlig når en av testene er litt "flaky".

Jeg tror vi har potensiale i å se litt nærmere på hvordan vi kan effektivisere "install" og "build"-stegene.

Se f. eks. https://glebbahmutov.com/blog/parallel-cypress-tests-gh-action/ for inspirasjon. Det ble også nevnt i #1574.

Det jeg ser for meg er en egen Action som gjør install og bygg. Så kan resten av jobbene (lint+typecheck+unit tester og cypress) hente cachet node_modules++ og laste ned bygget. Det bør kunne spare et par minutter. Samme prinsippet bør kunne funke på main med bygging av portalen og release også.

Jeg vil gjerne også at vi forsker litt på parallelisering av Cypress-testene. Det er en betalt feature (Cypress Dashboard), men det er noen hjemmesnekrede alternativer (finnes sikkert flere):

• outsideopen/cypress-e2e-parallel-test-action
• badeball/cypress-parallel
• tnicola/cypress-parallel

Noen som har erfaringer fra andre steder med enten "lenking" av actions eller parallelisering av Cypress?

[wkillerud]

Når vi er inne på cypress, jeg ser vi har installert cypress-axe, men det blir ikke brukt til noe. Vi kunne kanskje vurdert å erstatte det med cypress-audit for å få kombinert Lighthouse og pa11y-sjekker? Går an å sentralisere det i f. eks. testComponent-kommandoen.

[piofinn]

Vi kjørte axe-tester i noen av integrasjonstestene før, men det ble droppa på et eller annet tidspunkt. Tipper det bare er en spøkelsesavhengighet fra da 😊 cypress-audit så jo nice ut da!

[wkillerud]

Jeg eksperimenterer med noe jeg synes virker lovende på https://github.com/wkillerud/jokul/actions/runs/1394811129

Målet er å kutte ned til ett byggsteg som deles mellom lint+typecheck+test og Cypress, samtidig som Cypress splittes i tre runners. Har ikke helt fått dreisen på flyten mellom jobber i en workflow, men synes det virker lovende.

[wkillerud]

Jobber med å kutte ned byggtiden på Gatsby under oppgraderinga til Gatsby v4. Mesteparten av byggtiden går til å lage dokumentasjon for proptypes med react-docgen-typescript fordi den starter opp TypeScript-compileren en gang per fil. Ved å kjøre compileren én gang pekt på alle filene får vi kuttet ned byggetiden ganske heftig – fra ca et minutt i Bootstrap-steget ned til 12-13 sekunder. Coming soon.

[wkillerud]

Det med at Gatsby-bygget går fortere med ett kall til TypeScript i stedet for N = antall TypeScript-pakker fikk meg til å tenke. Kan vi kutte ned byggtiden for Jøkul generelt med det samme prinsippet?

Noen lovende bloggposter:

• https://maxrohde.com/2021/10/01/typescript-monorepo-with-yarn-and-project-references/
• https://semaphoreci.com/blog/typescript-monorepos-with-yarn
• https://cryogenicplanet.tech/posts/typescript-monorepo

Virker som en forutsetning er at vi bruker Yarn v2/v3. Det er kanskje noe vi uansett burde vurdere.

[wkillerud]

Utforsket dette litt i dag. Lerna er en blocker siden den mangler støtte for Yarn over versjon 1.x. Dersom vi finner en annen måte å versjonere alle pakker basert på conventional commits og SemVer, som samtidig tar høyde for avhengigheter mellom pakkene, så kan vi bytte til et sånt verktøy og la Yarn workspaces ta seg av resten.

https://psidium.github.io/lerna/monorepo/yarn/nodejs/pnp/zero-install/2021/08/23/migrating-a-monorepo-from-lerna-to-yarn-3.html

Fin bloggpost som går igjennom mye, men dessverre ikke nøkkelstegene for oss med versjonering og publisering ☝️

[wkillerud]

Ser her jeg kjører Cypress-testene lokalt i dag at mye tid brukes på å laste inn siden, og vi gjør minst to sidelastinger per testsuite: én hver for lyst og mørkt tema. Om hver sidelasting tar to-tre sekunder og vi har 27 tester kan vi i teorien spare et minutts tid bare på å strukturere om testkoden vår. En fordel med dagens løsning er at vi får en "hard reset" på eksempeltilstanden. En ulempe utover tid brukt på sidelasting er at vi i praksis kopierer testkoden med cy.setDarkMode(); som eneste forskjell mellom de to testene.