Eelmise kuu lõpus hakkasin rääkima ühikutestide kirjutamisest PHPUnitis WordPressi-põhise koodi jaoks. See hõlmas peamiselt PHPUniti seadistamise ideed, häälestusfunktsiooni japõhitestide kirjutamist.
See aga ei käsitlenud seda, mida ma tean tearDown funktsiooni kohta, mis on endiselt oluline testide abil kirjutamise funktsioon. Lisaks on WordPressi projektide jaoks testide kirjutamiseks kaks võimalust.
Nimelt:
- spetsiaalselt pistikprogrammide ja rakenduskihi funktsioonide jaoks mõeldud testide kirjutamine,
- WordPressi rakenduse üksusetestide käivitamine.
Enne selle konkreetse postitusega edasi liikumist soovitan siiski tutvuda sellega, mida olen seni käsitlenud. See hõlmab järgmisi postitusi:
- WordPressi arenduskeskkond (kasutades paketihaldurit)
- IDE WordPressi arendamiseks
- Visual Studio Code’i kasutajaseadetega töötamine
- Kirjutamisüksuse testid PHPUnitiga, 1. osa: Seadistamine
Kui olete seda teinud, naaske selle postituse juurde ja jätkame arutlemist funktsiooni tearDown ja selle üle, millised ühikutestid WordPressi kontekstis tegelikult välja näevad.
Ühikutestid PHPUnitiga, 2. osa: Rebimine
Enne edasiliikumist pidage meeles, et arendajad kohtlevad funktsiooni setUp sageli konstruktori ja rebimise funktsiooni hävitajana. aga pidage meeles, et viimast pole alati vaja.
Siin on hea rusikareegel, mida meeles pidada:
- Kõik, mida testfunktsioon vajab, kutsub esile setUp- funktsiooni, nii et vajalikud klassid on vajalikud.
- TearDown funktsiooni pole alati vaja, kuna funktsioon setUp võib klassi uuesti initsialiseerida .
Mida see tähendab funktsioonile tearDown, kui see ei lähtesta häälestusfunktsiooni käigus loodud andmeid ?
1 Rebimise funktsioon
Parim nõuanne, mida saan funktsiooni tearDown kohta anda, on see, et seda tuleks kasutada juhul, kui mõne testi ajal on midagi seadistatud, mis jääb maha.
See võib olla midagi, mis on kirjutatud andmebaasi, miski, mis on kirjutatud logisse, või üldisemalt midagi, mis on kirjutatud kõvakettale.
Seega, kui test kirjutab kirje või faili, käivitub rebimise meetod pärast testi ja peaks eemaldama kõik draivile salvestatud testid, mis ei ole testi osa, kuid mida ei ole järgmise testi jaoks püsivalt vaja. tuleks enda järelt ära koristada.
Nii et mõnes mõttes on see nagu hävitaja, kuid kui te pole kunagi kasutanud keelt, millel on hävitaja, tundub nomenklatuur kas ebaoluline või pole sellel mõtet.
Destruktor on spetsiaalne liigefunktsioon, mis kutsutakse välja objekti eluea lõppedes. Destruktori eesmärk on vabastada ressursid, mida objekt võis oma eluea jooksul omandada.
Seega on võib-olla parem mõelda funktsioonile lihtsalt testijärgse puhastamise viisina (ja mitte muutuja nullväärtuse määramises, kuna funktsioon setUp saab seda teha).
2 ühikutesti WordPressi projektide jaoks
WordPressi projektide jaoks ühikutestide kirjutamisel peame veenduma, et meil on selge, millist tüüpi ühikuteste me räägime.
Näiteks see, mida ma nimetan klassikalisteks või standardseteks ühikutestideks, järgib "testipõhise arenduse" metoodikat, millest räägin kohe. Teisest küljest on WordPressil oma ühikutestide komplekt teemade jms jaoks, millest räägin ka veidi hiljem selles postituses.
Kuid selle jaotise puhul arvasin, et võiks olla kasulik rääkida natuke esimesest, mitte teisest, et saaksite näha, kuidas see võiks toimida.
Allolevas näites kirjutan teste pistikprogrammi vastu, mis vastutab kolmanda osapoole API-ga suhtlemise eest. See konkreetne pistikprogramm nõuab kasutajanime ja parooli või API-d ning me tahame veenduda, et selle postituse jaoks hangib see testi käivitamisel vea õigesti.
Pange tähele, et seda koodi lugedes näete, et räägin natuke peegeldusest. Teen varsti terve postituse PHP Reflectioni kohta, nii et see heidab sellele veidi valgust.
Eeldage alloleva koodi puhul siiski, et see on viis, kuidas pääseme juurde atribuutidele, mis on muidu privaatseks märgitud.
Tuletame meelde selle seeria viimast postitust, meil oli esialgne test, mis nägi välja selline:
Pange tähele, et selles testis pole rebimise funktsiooni, mis oleks mõistlik, eks? Lõppude lõpuks ei kirjutata midagi andmebaasi ega faili.
Kuid oletame, et tahame tutvustada testjuhtumit, millel on failinimi, sisu ja mis kirjutab sisu faili. Sel juhul on need staatilised andmed, kuid tehniliselt võib see olla kõik, mis on kettale kirjutatud.
1 Testi seadistamine
Esiteks tahame testi seadistada, määratledes failinime, faili sisu ja valmistades ette atribuudid.
Piisavalt lihtne, eks?
2 Kirjutage ja lugege andmeid
Järgmisena tahame andmed kirjutada, andmeid lugeda ja kinnitada, et sisu on sama.
Kui käivitate testi (mida ma pole veel tehniliselt käsitlenud, kuidas seda teha), märkate, et fail testFile.txt asub endiselt teie süsteemis.
3 TearDowni kasutamine
Lõpuks peame kasutama tearDown meetodit, et veenduda, et fail kustutatakse pärast ühikutesti lõpetamist. Kui olete oma koodi rakendanud nii, nagu ülal näete , võib see välja näha järgmine.
Pange tähele, et tearDown meetodi puhul kontrollin esmalt, kas fail_exists. Selle põhjuseks on asjaolu, et kui proovite lihtsalt lahti linkida faili, mida pole, kuvatakse testide käivitamisel tõrketeade, sest kui tearDown on olemas, proovib see pärast iga testfunktsiooni midagi kustutada. Ja kui faili pole olemas, pole sellel midagi kustutada ja see põhjustab probleeme.
Seega, püüdes kirjutada koodi kaitsvalt, usun, et see vastutab faili olemasolu kontrollimise eest enne selle tegelikku kustutamist.
3 Toimingute järjekord
Kui rääkida puhtast ühikutestimisest, loete seda tavaliselt testipõhise arendusena. See on iseenesest suur teema; Siiski tasub siin mainida, kui otsustate seda edasi uurida ja isegi oma arendustegevuses rakendada.
Selle lähenemisviisi üldist ideed nimetatakse sageli "punaseks-roheliseks korduseks". Ja ma ei eita seda, selles lähenemises on midagi. Nimelt võimaldab see teil arendajana kirjutada koodi nii, nagu te eeldate, et see töötab enne koodi tegelikku kirjutamist.
Psühholoogia selle taga on järgmine: kui teate, kuidas kood töötab, kirjutate tõenäolisemalt teste, mis läbivad; samas kui kirjutate testid selle kohta, kuidas kood peaks toimima, peaksite kirjutama parema koodi.
Kahjuks ei ole meile alati seda luksust lubatud. Kuid see ei tähenda, et peaksime vanasõnalise lapse veega välja viskama. Selle asemel olen ma seda meelt, et peaksite võimalusel kirjutama teste ja pärast seda koodi kirjutama; vastasel juhul kirjutage oma testid oma koodi järele.
Lõppkokkuvõttes on testimine sellest hoolimata parem kui testide puudumine.
4 Testimine WordPressiga
Mis puutub WordPressi üksuste testimisse, siis olete tõenäoliselt mõne asja peale komistanud. Mõnikord on sisu vale nimetus või võib olla isegi eksitav WordPressi üksuse testimise osas.
Näiteks tasub tähelepanu pöörata kahele asjale:
- Teemaüksuse test. See konkreetne sisukomplekt on mõeldud selleks, et aidata teemaarendajatel testida oma teemade kõiki suuremaid ja väiksemaid juhtumeid. Näiteks pole automatiseeritud tööriistu, mida kasutaksite, nagu eespool käsitletu.
- Automatiseeritud testimine. WordPress tarnitakse koos oma ühikutestide komplektiga, et me ei peaks kirjutama teste enamiku WordPressi funktsioonide kohta (nt kas API funktsioonid töötavad ootuspäraselt või mitte). See võimaldab meil keskenduda oma domeeniloogika ühikutestide kirjutamisele.
- Plugina ühiku testid. Kui olete kasutanud WP-CLI-d (või olete sellest huvitatud), olete tõenäoliselt seda lehte lugenud või isegi seda tööriista kasutanud. See on kasulik, kuid sihib ka WordPressi pistikprogrammide testimise konkreetseid aspekte.
Kõik eelnev on kasulik teave ja ma ei ütle, et seda tuleks ignoreerida. Selle asemel tuleks see ühendada ülejäänud selles postituses kasutatud teabega.
Ühikutestide käivitamine
Järgmises postituses tutvustan teile kõike, mida peate teadma XML-faili seadistamiseks, mis annab PHPUnitile teada, kus testid asuvad ja kuidas neid käivitada.
Praegu aga vaadake üle selles postituses olev kood ja valmistuge selle seeria järgmises postituses sellest edasi ehitama.