Selle kuu alguses hakkasime uurima PHPUniti installimist Visual Studio Code’i, mille lõppeesmärk oli õppida kirjutama oma WordPressi-põhiste projektide jaoks ühikuteste.
Selleks eeldatakse selles postituses, et olete lugenud järgmisi postitusi, ja eeldatakse, et olete jõudnud järele mõnele varasemale postitusele:
- WordPressi arenduskeskkond (kasutades paketihaldurit)
- IDE WordPressi arendamiseks
- Visual Studio Code’i kasutajaseadetega töötamine
Ja muidugi PHPUniti installimine Visual Studio Code’i, nagu ülal linkitud. Kui see on tehtud, oleme valmis jätkama. Kuid üks asi, mida tuleb meeles pidada, on see, et see õhtu on traditsiooniline või põhjalik ühikutestide kirjutamise kursus.
Selle asemel on tegemist WordPressi projektide ühikutestide kirjutamisega.
Ühikutestid PHPUnitiga, 1. osa: Seadistamine
Enne sellesse liiga süvenemist tahan teha selgeks, et see pole niivõrd postitus testipõhises arenduses, vaid postitus, mis paneb aluse kirjutamisühikutestide mõistmisele. Ja siis lõpuks töötame selle nimel, et kirjutada oma koodi jaoks ühikutestid.
Neile teist, kes on üksuse testimise kohta varem lugenud, teate, et ühikutestide kirjutamine on teema, mille kohta on palju teavet ja see postitus ei püüa seda kõike hõlmata. Selle asemel läheneb see WordPressi-põhiste pistikprogrammide, veebirakenduste ja muude sarnaste testide kirjutamisel pragmaatilisemalt.
1 Kirjutamisüksuse testid
Iga kord, kui asute esimest korda ühikutestide kirjutamisse, tutvustatakse teile nii seadistamise kui ka rebimise meetodi ideed. See on PHPUnitis tavaline (nagu ka teiste testimisraamistike puhul). Nende kahe konkreetse meetodi puhul on mõned asjad, mis sageli probleeme põhjustavad.
Lühidalt, inimesed kohtlevad funktsioone järgmiselt:
- SetUp on nagu konstruktor, kus loote oma klassi ja seejärel valmistate ette kõik, mida oma testi jaoks vajate, sealhulgas testitav objekt, vajalikud andmed ja nii edasi.
- tearDown on hävitaja, kus saate kõik lähtestada ja seejärel oma objektid ära visata. See on tavaliselt kompileeritud keeltes tavalisem, kuid seda ei tohiks mainimata jätta ka PHPUniti puhul.
Ja kuigi ma saan sellest täiesti aru, pole see alati nii. Ma räägin ka siin oma kogemusest. Selle asemel tuleb tegelik fraasiühiku testimine siit. See kõik puudutab üksuste koodikoodi testimist ja seda puhtal ja kokkuvõtlikul viisil.
Milleks need meetodid siis ikkagi on? See võib olla eriti raske harjumusest lahti saada või isegi kontseptuaalne mudel, millest protsessi esimest korda sisenedes murda. Selleks tahan uurida iga meetodi eesmärki ja seejärel seda, kuidas sellele WordPressi-põhiste projektidega töötades läheneda.
Ja nagu tavaliselt, püüan hoida seda võimalikult lihtsa ja pragmaatilisena. Mind huvitab palju vähem teatud asjade taga olev teooria kui see, kuidas see nii minu ärile kui ka projektidele hästi sobib. (See ei ole muidugi teooria allahindlus, kuid selleks on aeg, mitte koht ja see blogi pole see.)
2 Seadistusfunktsioon
Kuigi alustan häälestusmeetodi lühikese aruteluga, on oluline meeles pidada, et selle sõsarfunktsiooni (nagu mõned arvavad) pole alati vaja.
Näiteks kui kirjutate koodi, kus te muudate ainult objekti või objektide komplekti, siis ei pruugi tearDown meetodit vaja minna. Ma käsitlen seda üksikasjalikumalt järgmises jaotises.
Seda arvestades oletame, et teil on klass, mis vastutab teatud domeeniloogika täitmise eest. Pidage meeles, et selle postituse jaoks ei huvita me koodi, mis teeb asju, mida WordPress teeb loomulikult ja millel on juba oma testide komplekt.
Selle all pean silmas, et me oleme mures koodi pärast, mis töötab konkreetselt probleemses valdkonnas. Näiteks võib-olla oleme huvitatud klassi kirjutamisest, mis salvestab andmed andmebaasi vahemällu. Üks teabeosadest, mis vastutab teabe vahemällu salvestamise eest, on see, kui kaua andmed peaksid vahemälus olema. Seega kasutaks ühikutesti kandidaat seda, et me saame aja määrata ja muuta, eks?
Tõsi, võib-olla on need andmed kõvasti kodeeritud, kuid näiteks oletame teisiti. See tähendab järgmist:
- Meil on klass, mis toimib meie vahemäluna,
- Klass säilitab eksemplari andmete tükki, kui kaua vahemälu tuleks seadistada,
- Vahemälu aega saab määrata kolmandate osapoolte klassidest,
- Vahemälu aega saab lugeda kolmandate osapoolte klassidest.
See tähendab, et ühikutest peaks sisaldama:
- Klassi seadistamine,
- Väärtuse määratlemine,
- Kinnitades, et defineeritud väärtus on ootuspärane,
- Väärtuse muutmine,
- Muudetud väärtuse kinnitamist värskendati.
Seega võib põhiklass välja näha umbes selline (kogu dokumentatsioon on klassist välja jäetud, et kood oleks võimalikult lühike):
Pange tähele, et vaikimisi on vahemälu aeg 12 tundi (sekundites). Tund toetab nii kestuse muutmise kui ka lugemise võimalust.
See tähendab, et saame kirjutada teste, mis testivad:
- kui algväärtus on ootuspärane,
- kui uus väärtus on ootuspärane (ja et see kirjutab algväärtuse üle)
Üks asi, millele tahaksin ülaltoodud koodis tähelepanu juhtida, on see, et võite lugeda, et igal testil peaks olema üks väide, samas kui testNewDurationil on selgelt kaks väidet.
Kipun võtma rusikareeglina ideed ühest väitest testi kohta. Näiteks sel juhul tahan kinnitada, et algväärtus kirjutatakse üle või ei salvestata kuhugi ja uus väärtus salvestatakse.
See ei pruugi aga alati nii olla, seega peate võib-olla seda tüüpi olukordi ettevaatlikult käsitlema.
Nagu näete, pole sellel WordPressiga mingit pistmist; see on aga seotud konkreetselt antud domeeniga seotud testimisloogikaga. Nimelt vahemälu kestus. Ja selles seisnebki ühikutestimise tuum: koodiühikute loogilise käitumise testimine, et veenduda, et asjad toimivad ootuspäraselt.
Ja sõltuvalt sellest, millal selle koodi kirjutate, võivad teil testid ebaõnnestuda. See võib lõppkokkuvõttes aidata klassi kujundamisel, kuid see on teine teema, mitte selle postituse osa.
Testide käivitamine
Kui testid on kirjutatud, on oluline osata neid täita, et näha, kas need läbivad, kui ebaõnnestuvad, mis läbib ja mis mitte. Kuid me pole veel lõpetanud. Soovin anda põhjaliku ülevaate üksuste testimisest WordPressi kontekstis. See tuleneb sellest, mida WordPress pakub, mida mitte, mõningaid väärarusaamu ja kuidas neid teste terminalis või Visual Studio Code’is käivitada.
Selle seeria järgmises postituses vaatleme tearDowni funktsiooni ja seda, kuidas (ja millal) seda kasutada, millal seda vaja on, millal mitte, ja seejärel vaatame veidi ühikut. testimine WordPressis üldiselt.
Lõppkokkuvõttes töötame selle nimel, et saada täielik ülevaade sellest, kuidas seda teha ja kuidas seda õigesti teha. Kuid oluline on sellele alus panna ja seda on mõne posti ulatuses lihtsam teha kui ühes monoliitses postis.
Seega on selle sarja järgmise postituse teemaks tearDown(), selle kasutamise ja käsurealt testide sooritamise uurimine.