-
Notifications
You must be signed in to change notification settings - Fork 3
FI 2.1 cypress
Hacklab Helsinki #web-kehitys
kurssi 21.4.2021 -
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ä!
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.
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.
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 komennotcypress/support
:n alaisuudessa.
- 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)
- 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?
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!
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ä:
-
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.
-
...Do not test what does not need testing.
-
write partial tests that drive your application step by step, writing your test and application code at the same time.
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)
-
.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.
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.
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ä.
Työt tulee tehdyksi. Testit nopeuttavat etenemistäsi - eivät hidasta sitä.
Seuraavaksi: Front-endin tuotantopaketointi ja toimitus