Kirjoitusyksikkötestit PHPUnitilla, Osa 1: Asennus
Aiemmin tässä kuussa aloimme harkita PHPUnitin asentamista Visual Studio Codeen lopullisena tavoitteenamme oppia kirjoittamaan yksikkötestejä WordPress-pohjaisille projekteillemme.
Tätä varten tässä viestissä oletetaan, että olet lukenut seuraavat viestit ja että olet lukenut kourallisen aikaisempia viestejä:
- WordPress-kehitysympäristö (käyttämällä paketinhallintaa)
- IDE WordPressin kehittämiseen
- Käyttäjäasetusten käyttäminen Visual Studio Codessa
Ja tietysti PHPUnitin asentaminen Visual Studio Codessa yllä olevan linkin mukaisesti. Kun se on tehty, olemme valmiita jatkamaan. Mutta yksi asia on pidettävä mielessä, että tämä ilta on perinteinen tai kattava yksikkökokeiden kirjoittamisen kurssi.
Sen sijaan kyse on yksikkötestien kirjoittamisesta WordPress-projekteille.
Yksikkötestit PHPUnitilla, Osa 1: Asennus
Ennen kuin menen liian syvälle tähän, haluan tehdä selväksi, että tämä ei ole niinkään testivetoisen kehityksen postaus, vaan postaus, joka luo pohjan kirjoitusyksikkötestien ymmärtämiselle. Ja sitten viime kädessä pyrimme kirjoittamaan koodillemme yksikkötestejä.
Niille teistä, jotka ovat aiemmin lukeneet yksikkötestauksesta, tiedätte, että yksikkötestien kirjoittaminen on aihe, josta on paljon tietoa, eikä tämä viesti yritä kattaa kaikkea sitä. Sen sijaan se ottaa pragmaattisemman lähestymistavan yksikkötestien kirjoittamiseen WordPress-pohjaisia laajennuksia, verkkosovelluksia ja vastaavia vastaan.
1 kirjoitusyksikkötestit
Aina kun aloitat yksikkötestien kirjoittamisen, sinulle esitetään sekä idea setUp- että tearDown- menetelmistä. Tämä on yleistä PHPUnitissa (kuten muissakin testauskehyksissä). Näissä kahdessa menetelmässä on muutamia asioita, jotka usein aiheuttavat ongelmia.
Lyhyesti sanottuna ihmiset käsittelevät toimintoja seuraavasti:
- setUp on kuin konstruktori, jossa luot luokkasi ja valmistelet sitten kaiken, mitä tarvitset testiä varten, mukaan lukien testattava objekti, tarvittavat tiedot ja niin edelleen.
- tearDown on tuhoaja, jossa nollaat kaiken ja hävität sitten esineesi. Tämä on yleensä yleisempää käännetyillä kielillä, mutta sitä ei kannata jättää väliin myös PHPUnitissa.
Ja vaikka ymmärrän tämän täysin, se ei aina ole niin. Puhun täälläkin kokemuksesta. Sen sijaan varsinainen lauseyksikkötestaus tulee tästä. Kyse on yksiköiden koodikoodin testaamisesta ja sen tekemisestä puhtaalla, ytimekkäällä tavalla.
Joten mitä varten nämä menetelmät ovat? Tämä voi olla erityisen vaikea murtaa tapa tai jopa käsitteellinen malli, joka voi olla murrettavissa, kun olet ensimmäistä kertaa mukana prosessissa. Tätä varten haluan tarkastella kunkin menetelmän tarkoitusta ja sitten sitä, kuinka lähestyä tätä työskennellessäni WordPress-pohjaisten projektien kanssa.
Ja kuten tavallista, pyrin pitämään tämän mahdollisimman yksinkertaisena ja pragmaattisena. Olen paljon vähemmän kiinnostunut tiettyjen asioiden taustalla olevasta teoriasta kuin siitä, kuinka se palvelee hyvin sekä liiketoimintaani että projektejani. (Tämä ei tietenkään ole teorian vähättelyä, mutta sille on aika, ei paikka, eikä tämä blogi ole sitä.)
2 Asetustoiminto
Vaikka aloitan lyhyellä keskustelulla setUp -menetelmästä, on tärkeää pitää mielessä, että sen sisartoimintoa (jotenkin mielestä) ei aina tarvita.
Jos esimerkiksi kirjoitat koodia, jossa vain luot objektin tai objektijoukon, tearDown- menetelmää ei ehkä tarvita. Käsittelen tätä tarkemmin seuraavassa osiossa.
Oletetaan, että sinulla on luokka, joka on vastuussa verkkotunnuksen logiikan suorittamisesta. Muista, että tämän viestin tarkoituksia varten emme ole huolissamme koodista, joka tekee asioita, joita WordPress tekee luonnollisesti ja jolla on jo omat testinsä.
Tällä tarkoitan, että olemme huolissamme koodista, joka toimii nimenomaan ongelma-alueella. Esimerkiksi ehkä olemme huolissamme luokan kirjoittamisesta, joka tallentaa tiedot välimuistiin tietokantaan. Yksi tiedoista, jotka vastaavat tietojen tallentamisesta välimuistiin, on se, kuinka kauan tietojen tulee olla välimuistissa. Siten ehdokas yksikkötestiin käyttäisi sitä, että voimme asettaa ja muuttaa ajan, eikö niin?
Myönnettäköön, ehkä nämä tiedot ovat kovakoodattuja, mutta esimerkiksi oletetaan toisin. Tämä tarkoittaa seuraavaa:
- Meillä on luokka, joka toimii välimuistina,
- Luokka ylläpitää ilmentymätietoa niin kauan kuin välimuisti tulee asettaa,
- Välimuistin aika voidaan asettaa kolmannen osapuolen luokista,
- Välimuistin aika voidaan lukea kolmannen osapuolen luokista.
Tämä tarkoittaa, että yksikkötesti sisältää:
- Luokan perustaminen,
- arvon määrittäminen,
- Vahvistaa, että määritetty arvo on odotetusti,
- Arvon muuttaminen,
- Muutetun arvon vahvistaminen päivitettiin.
Perusluokka voi siis näyttää suunnilleen tältä (kaikki dokumentaatio jätetään luokasta pois, jotta koodi pysyisi mahdollisimman ytimekkäänä):
Huomaa, että oletuksena välimuistin ajaksi on asetettu 12 tuntia (sekunneissa). Tunti tukee kykyä sekä muuttaa että lukea kestoa.
Tämä tarkoittaa, että voimme kirjoittaa testejä, jotka testaavat:
- jos alkuperäinen arvo on odotettu,
- jos uusi arvo on odotettu (ja että se korvaa alkuperäisen arvon)
Yksi asia, jonka haluan korostaa yllä olevassa koodissa, on se, että voit lukea, että jokaisessa testissä pitäisi olla yksi väite, kun taas testNewDurationissa on selvästi kaksi väitettä.
Minulla on tapana pitää ajatusta yhdestä väitteestä testiä kohti peukalosääntönä. Esimerkiksi tässä tapauksessa haluan vakuuttaa, että alkuperäinen arvo kirjoitetaan päälle tai sitä ei tallenneta minnekään ja uusi arvo tallennetaan.
Näin ei kuitenkaan aina ole, joten saatat joutua käsittelemään tämäntyyppisiä tilanteita varoen.
Kuten näet, tällä ei ole mitään tekemistä WordPressin kanssa; se liittyy kuitenkin testauslogiikkaan, joka liittyy erityisesti kyseiseen verkkotunnukseen. Nimittäin välimuistin kesto. Tämä on yksikkötestauksen ydin: koodiyksiköiden loogisen toiminnan testaaminen varmistaaksemme, että asiat toimivat odotetulla tavalla.
Ja riippuen siitä, milloin kirjoitat tämän koodin, sinulla voi olla epäonnistuneita testejä. Tämä voi viime kädessä auttaa luokan suunnittelussa, mutta se on toinen aihe, joka ei ole osa tätä viestiä.
Testien suorittaminen
Kun testit on kirjoitettu, on tärkeää pystyä suorittamaan ne, jotta näet, läpäisevätkö ne, epäonnistuvatko, mikä läpäisee ja mikä ei. Mutta emme ole vielä valmiita. Haluan tarjota kattavan katsauksen yksikkötestaukseen WordPressin kontekstissa, ja tässä keskustellaan siitä, mitä WordPress tarjoaa, mitä se ei, joitain väärinkäsityksiä ja kuinka nämä testit suoritetaan päätteessä tai Visual Studio Codessa.
Tämän sarjan seuraavassa postauksessa tarkastelemme tearDown- toimintoa ja kuinka (ja milloin) sitä käytetään, milloin sitä tarvitaan, milloin ei, ja sitten tarkastellaan hieman yksikön ympärillä. testaus WordPressissä yleensä.
Viime kädessä pyrimme saamaan täydellisen kuvan siitä, kuinka tämä tehdään ja miten se tehdään oikein. Mutta sille on tärkeää luoda perusta, ja sen tekeminen muutaman pylvään aikana on helpompaa kuin yhdessä monoliittisessa pylväässä.
Joten tearDown() :n tutkiminen, sen käyttö ja testien suorittaminen komentoriviltä on tämän sarjan seuraavan postauksen aihe.