Skip to content

FI 2.1 cypress

Asko Kauppi edited this page Apr 29, 2021 · 4 revisions

Hacklab Helsinki #web-kehitys kurssi 21.4.2021 -

2. Sovellus (front-end)

2.1 Testaus Cypress:lla

Cypress on web-sivustojen ja sovellusten testaukseen tehty työväline, josta voisi pitää aivan oman kurssinsa.

Kuten muutenkin tällä kurssilla, aloitetaan käytännöllä!

Ensimmäinen käynnistys

Linux ja macOS:

$ npx cypress open
...

Tämä komento käynnistää Cypress:n työpöytäsovelluksen, jonka kautta testit ajetaan.

macOS: Kiinnitä ohjelma Dockiin (ikoni > Valinnat > Pidä Dockissa), josta voit sen seuraavilla kerroilla käynnistää.

Sulje ohjelma (pääte vapautuu). Avaa se uudelleen ikonista.

Windows 10: Käynnistä erikseen asentamasi Cypress-ohjelmisto.

Käytät komentorivillä Cypressin Linux-versiota ja desktop-käytössä sen Windows-versiota. Koska nämä molemmat näkevät projektisi tiedostot ja portin (3000), homma toimii.

Projektin avaus

Avaa projektin packages/app-kansio Cypressissa. Pitäisi näyttää tältä:

Käytämme Cypress-testien ajoon samaa npm run dev-serveriä, jota aikaisemmin käytimme selaimen kanssa. Jos Cypress sanoo, ettei löydä palvelinta, käynnistä se (npm run dev) ja kokeile uudelleen.

Hyvä!

Mitä UI:ssa näkyy? Miten ajaisit tällä testejä? Kokeillaan.

Interaktiivinen testaus

Testit on jaettu cypress-alihakemistossa "tarinansa" (user story) mukaan:

cypress
├── anonymous           # case, jossa käyttäjällä ei ole tunnusta
│   └── guest.spec.js
├── commands
│   └── index.js
├── joe                 # tunnuksella olevan käyttäjän tekemisiä
│   └── signInAs.spec.js
└── users.js

users.js ja commands sisältävät testien suorittamisen yleisiä työkaluja.

Huom: Cypressin oletusnimeämiskäytäntö on erilainen. Siinä testit ovat cypress/integration-hakemistossa ja komennot cypress/support:n alaisuudessa.

Joe

  • Avaa IDE:en cypress/joe/signInAs.spec.js

Mitä oletat testikoodin perusteella testattavan?

  • Ajetaan testi

  • Tutustutaan time travel:iin (levitoi hiirellä testirivien päällä)
  • ..ja tietyn testin kiinnittämiseen (pin down)

Anonymous

  • Sama cypress/anonymous/guest.spec.js:lle.

Tässä testissä on lisäjännitteenä se, että testattava pala on "web component". Miten se vaikuttaa testikoodiin?

Kaikkien testien ajo kerralla

Testipohjaisessa kehittämisessä sinulla on auki yksi testi, jota (ja sovelluksen koodia) viilaat. Kokonaan toinen tapa ajaa testit on ajaa ne kaikki kerralla.

$ npm test

Kokeillaan.

Tätä tapaa käytetään yleensä CI/CD:ssä tarkistamaan, että "tavara on kunnossa" ennen esim. version toimittamista pilveen. Näin kehittäjän testit ja tuotannon testit nivoutuvat yhteen!

Cypressin TL;DR

Olisi oikeastaan parasta tutustua Cypressiin syvästi. Tässä on joitain kohtia, jotka kurssin pitäjän mielestä (ja tämän repon käytännön osalta) ovat merkityksellisiä:

  • Key differences

    Cypress is executed in the same run loop as your application.

    Cypress ultimately controls the entire automation process from top to bottom, which puts it in the unique position of being able to understand everything happening in and outside of the browser.

  • ...

    Cypress prevents you from being forced to always 'act like a user' to generate the state of a given situation.

  • ...

    ...it automatically waits for elements to become visible, to become enabled, and to stop being covered.

  • Trade-offs

    ...Do not test what does not need testing.

  • Best Practises

    write partial tests that drive your application step by step, writing your test and application code at the same time.

Cypressin ainutlaatuisuus

Web-sivujen testialustoja on ollut paljon.

Cypress eroaa aiemmista siinä, että:

  • testit ajetaan browserin sisällä (voit käyttää sen normaaleja kehitystyökaluja, kuten debugger keskellä testiä!)
  • testeillä on silti pääsy myös suoraan taustajärjestelmiin (cy....); voit jopa ajaa komentoja kehityskoneen käyttöjärjestelmätasolla

Cypress automaattisesti odottaa, kunnes testisi kuvaama tilanne tapahtuisi. Sen ei siis tarvitse heti olla voimassa. Riittää, että ennen timeout:ia se on kertaalleen voimassa. Tämä yksinkertaistaa selaintestien kirjoittamista suunnattomasti! ☀️

Lisäherkkuina Cypress tarjoaa:

  • 🍧 aikamatkailun testin askelten yli - näet, mitä ruudulla milloinkin oli!
  • 🍰 kuvat tai videot selaimen sisällöstä! (esim. vain testeistä, jotka eivät menneet läpi)

Cypress:in kanssa varottavaa

  • .then ("Chainables") ei ole sama kuin EcmaScript Promise, vaikka rajapinta näyttää samalta.

    ks. Cypress.io - Using async and await (blog, Apr 2018)

    cy.wrap toimii välittäjänä näiden kahden maailman välillä (mutta on vähän kömpelö - eikä sitä näytetä aina tarvittavan..).

    Tällaiset asiat kannattaa laittaa sivuun itse testeistä, omiksi Cypress-"komennoiksi" (kuten cypress/commands/auth.js).

  • Paketointi ei ole ES-moduulimainen

    Kaikki toimii cy.jotain -tyylisesti. Tämä tuntuu vähän oudolta, jos on ennättänyt tottua ES-modulimaiseen käytäntöön. On kuitenkin Cypressille ominaista.

Testipohjaisen kehityksen filosofiaa 🧙‍♂️

Testipohjainen kehitys tarkoittaa mm. sitä, että:

  • ajattelet testit ensin - mitä ohjelman tulisi tehdä?
  • kirjoitat testit ensin
  • aja testi ennen kuin se edes toimii
  • tee koodimuutokset niin, että testi toimii

Tämä on oikeastaan leikki!

Testipohjaisen kehityksen etuja on aika paljon (käsin testattavaan verrattuna):

  • koodi tulee mietittyä pienemmissä paloissa
  • on helpompi huomata, jos jotain meni rikki (= vähentää stressiä!)
  • asioista on helpompi keskustella pomon/tiimin/asiakkaan kanssa (= parantaa kommunikaatiota!)

Tässä mennään kokemuspohjaisille alueille. Jos et ole aiemmin kokeillut testipohjaista kehitystä, Cypress tarjoaa siihen upeat välineet.

Mitä tulee testata?

Kaikkea ei tarvitse testata.

Jos jokin menee rikki, ja se "sattuu", sille olisi kannattanut olla testi!

Mitään ei kannata testata kahdesti. Eli tee toisistaan riippumattomia testejä.

Mistä tietää, että testaa oikein?

Työt tulee tehdyksi. Testit nopeuttavat etenemistäsi - eivät hidasta sitä.


Seuraavaksi: Front-endin tuotantopaketointi ja toimitus