Kirjoitusyksikkötestit PHPUnitilla, Osa 2: Tear Down
Viime kuun lopulla aloin puhua yksikkötestien kirjoittamisesta PHPUnitissa WordPress-pohjaiselle koodille. Tämä sisälsi ensisijaisesti ajatuksen PHPUnit: n asettamisesta, setUp – funktiosta ja perustestien kirjoittamisesta.
Tämä ei kuitenkaan käsitellyt sitä, mitä tiedän tearDown- toiminnosta, joka on edelleen tärkeä ominaisuus testeillä kirjoittamisessa. Lisäksi on myös kaksi tapaa harkita testien kirjoittamista WordPress-projekteihin.
Nimittäin:
- kirjoitustestit erityisesti laajennuksia ja sovellustason toimintoja varten,
- yksikkötestien suorittaminen WordPress-sovellusta vastaan.
Ennen kuin siirryt eteenpäin tässä postauksessa, suosittelen kuitenkin perehtymään siihen, mitä olen käsitellyt tähän mennessä. Tämä sisältää seuraavat viestit:
- WordPress-kehitysympäristö (käyttämällä paketinhallintaa)
- IDE WordPressin kehittämiseen
- Käyttäjäasetusten käyttäminen Visual Studio Codessa
- Kirjoitusyksikkötestit PHPUnitilla, Osa 1: Asennus
Kun olet tehnyt sen, palaa tähän viestiin ja jatketaan keskustelua tearDown-toiminnosta ja siitä, miltä yksikkötestit WordPressin yhteydessä todella näyttävät.
Yksikkötestit PHPUnitilla, Osa 2: Tear Down
Ennen kuin siirryt eteenpäin, muista, että kehittäjät kohtelevat usein setUp -funktiota kuin rakentajaa ja tearDown- funktiota kuin tuhoajaa. Muista kuitenkin, että jälkimmäistä ei aina tarvita.
Tässä on hyvä peukalosääntö muistaa:
- Kaikki testifunktion tarpeet kutsuvat setUp – funktiota, jotta tarvittavat luokat tarvitaan.
- TearDown – toimintoa ei aina tarvita, koska setUp – toiminto voi alustaa luokan uudelleen.
Joten mitä tämä tarkoittaa tearDown- toiminnolle, jos se ei nollaa tietoja, jotka on luotu asetustoiminnon aikana ?
1 Repäisytoiminto
Paras neuvo, jonka voin antaa tearDown- toiminnon suhteen, on se, että sitä tulisi käyttää, jos jokin jää jäljelle jääneen testin aikana.
Tämä voi olla jotain, joka on kirjoitettu tietokantaan, jotain, joka on kirjoitettu lokiin, tai yleisemmin jotain, joka on kirjoitettu kiintolevylle.
Näin ollen, jos testi kirjoittaa tietueen tai tiedoston, tearDown- menetelmä suoritetaan testin jälkeen ja sen pitäisi poistaa asemalle tallennetut testit, jotka eivät ole osa testiä, mutta joita ei tarvita pysyvästi seuraavaa testiä varten tai pitäisi siivota itsensä jälkeen.
Joten tietyssä mielessä se on kuin tuhoaja, mutta jos et ole koskaan käyttänyt kieltä, jolla on tuhoaja, nimistö joko vaikuttaa epäolennaiselta tai siinä ei ole järkeä.
Tuhoaja on erityinen jäsenfunktio, jota kutsutaan, kun objektin elinikä päättyy. Tuhoajan tarkoitus on vapauttaa resurssit, jotka esine on saattanut hankkia elinaikanaan.
Siksi ehkä on parempi ajatella funktiota yksinkertaisesti tapana puhdistaa testin jälkeen (eikä siinä mielessä, että muuttuja asetetaan yhtä suureksi kuin null, koska setUp – funktio voi tehdä sen).
2 yksikkötestiä WordPress-projekteille
Kun kirjoitamme yksikkötestejä WordPress-projekteille, meidän on varmistettava, että olemme selvillä siitä, minkä tyyppisistä yksikkötesteistä puhumme.
Esimerkiksi se, mitä kutsun klassisiksi tai vakioyksikkötesteiksi, noudattaa "testilähtöistä kehitystä" -metodologiaa, josta puhun hetken kuluttua. Toisaalta WordPressillä on omat yksikkötestit teemoille ja vastaaville, joista kerron myös hieman myöhemmin tässä postauksessa.
Mutta tässä osiossa ajattelin, että voisi olla hyödyllistä puhua hieman edellisestä jälkimmäisen sijaan, jotta näet, kuinka tämä voisi toimia.
Alla olevassa esimerkissä kirjoitan testejä laajennukselle, joka vastaa viestinnästä kolmannen osapuolen API:n kanssa. Tämä lisäosa vaatii käyttäjätunnuksen ja salasanan tai API :n, ja haluamme varmistaa, että tämän viestin tarkoituksia varten se hakee virheen oikein aina, kun testi suoritetaan.
Huomaa, että kun luet tätä koodia läpi, näet minun puhuvan hieman heijastuksesta. Aion tehdä koko postauksen PHP Reflectionista pian, joten se valaisee tätä.
Oletetaan kuitenkin, että alla olevan koodin tapauksessa voimme päästä käsiksi kiinteistöihin, jotka on muuten merkitty yksityisiksi.
Muista tämän sarjan viimeinen viesti, meillä oli ensimmäinen testi, joka näytti tältä:
Huomaa kuitenkin, että tässä testissä ei ole tearDown- toimintoa, joka olisi järkevä, eikö niin? Loppujen lopuksi mitään ei kirjoiteta tietokantaan tai tiedostoon.
Mutta oletetaan, että haluamme ottaa käyttöön testitapauksen, jossa on tiedostonimi, sisältö ja se kirjoittaa sisällön tiedostoon. Tässä tapauksessa se tulee olemaan staattista dataa, mutta se voi teknisesti olla mitä tahansa levylle kirjoitettua.
1 Testin määrittäminen
Ensin haluamme määrittää testin määrittämällä tiedostonimen, tiedoston sisällön ja valmistelemalla ominaisuudet.
Tarpeeksi helppoa, eikö?
2 Kirjoita ja lue tietoja
Seuraavaksi haluamme kirjoittaa tiedot, lukea tiedot ja vakuuttaa, että sisältö on sama.
Tässä vaiheessa, jos suoritat testin (jonka tekemiseen en ole vielä perehtynyt teknisesti), huomaat, että testFile.txt on edelleen järjestelmässäsi.
3 TearDownin käyttäminen
Lopuksi meidän on työskenneltävä tearDown- menetelmän kanssa varmistaaksemme, että tiedosto poistetaan yksikkötestin päätyttyä. Tältä se voi näyttää, jos olet ottanut koodisi käyttöön yllä olevan kuvan mukaisesti.
Huomaa, että tearDown- menetelmässä tarkistan ensin, onko file_exists. Tämä johtuu siitä, että jos yrität yksinkertaisesti poistaa linkityksen tiedostosta, jota ei ole, saat virheilmoituksen suorittaessasi testejä, koska jos tearDown on olemassa, se yrittää poistaa jotain jokaisen testitoiminnon jälkeen. Ja jos tiedostoa ei ole olemassa, sillä ei ole mitään poistettavaa, joten se aiheuttaa ongelman.
Joten yritän kirjoittaa koodia puolustavasti, uskon sen olevan vastuussa tiedoston olemassaolon tarkistamisesta ennen sen poistamista.
3 Toimintajärjestys
Kun kyse on puhtaasta yksikkötestauksesta, luet tämän yleensä testilähtöisen kehityksen kannalta. Tämä on iso aihe sinänsä; On kuitenkin syytä mainita tässä, jos päätät tutkia sitä edelleen ja jopa ottaa sen käyttöön kehitystyössäsi.
Tämän lähestymistavan taustalla olevaa yleistä ajatusta kutsutaan usein "punavihreäksi toistoksi". Ja en kiellä sitä, tässä lähestymistavassa on jotain. Nimittäin sen avulla voit kehittäjänä kirjoittaa koodin sellaisena kuin odotat sen toimivan ennen kuin kirjoitat koodin.
Sen takana oleva psykologia on seuraava: Jos tiedät kuinka koodi toimii, kirjoitat todennäköisemmin testejä, jotka läpäisevät; kun taas jos kirjoitat testejä koodin suorituskyvystä, sinun tulee kirjoittaa parempi koodi.
Valitettavasti meillä ei aina ole varaa siihen ylellisyyteen. Mutta se ei tarkoita, että meidän pitäisi heittää sananlasku vauva ulos veden kanssa. Sen sijaan olen sitä mieltä, että sinun pitäisi kirjoittaa testejä, kun voit, ja kirjoittaa koodi sen jälkeen; muussa tapauksessa kirjoita testisi koodisi jälkeen.
Loppujen lopuksi testaus siitä riippumatta on parempi kuin ei testejä ollenkaan.
4 Testaus WordPressillä
Mitä tulee yksikkötestaukseen WordPressissä, olet todennäköisesti törmännyt muutamaan asiaan. Joskus sisältö on harhaanjohtavaa tai jopa harhaanjohtavaa "WordPressin yksikkötestauksen" suhteen.
Tässä tapauksessa on kaksi huomionarvoista asiaa:
- Teemayksikkötesti. Tämä sisältösarja on tarkoitettu auttamaan teemakehittäjiä testaamaan kaikki tärkeimmät ja pienet tapaukset teemoilleen. Ei ole olemassa esimerkiksi automatisoituja työkaluja, joita käyttäisit kuten edellä käsitellessämme.
- Automaattinen testaus. WordPress toimitetaan omilla yksikkötesteillä, joten meidän ei tarvitse kirjoittaa testejä useimpia WordPressin toimintoja vastaan (kuten toimivatko API-toiminnot odotetulla tavalla vai eivät). Tämän ansiosta voimme keskittyä oman verkkoalueen logiikkamme yksikkötestien kirjoittamiseen.
- Plugin Unit Tests. Jos olet käyttänyt WP-CLI:tä (tai olet kiinnostunut siitä), olet todennäköisesti lukenut tämän sivun tai jopa käyttänyt tätä työkalua. Se on hyödyllinen, mutta se kohdistuu myös tiettyihin WordPress-laajennusten testaamiseen.
Kaikki yllä oleva on hyödyllistä tietoa, enkä tarkoita, että niitä tulisi jättää huomiotta. Sen sijaan se tulisi yhdistää muuhun tässä viestissä käytettyyn tietoon.
Yksikkötestien suorittaminen
Seuraavassa viestissä opastan sinut läpi kaiken, mitä sinun tarvitsee tietää määrittääksesi XML-tiedoston, joka kertoo PHPUnitille testien sijainnin ja niiden suorittamisen.
Tarkista kuitenkin toistaiseksi tässä viestissä oleva koodi ja valmistaudu rakentamaan sitä tämän sarjan seuraavassa viestissä.