Mida rohkem ma WordPressis töötan, seda rohkem püüan muuta ühikutestimise oma arenduse osaks, kui tegeliku funktsioonikomplekti väljatöötamiseks. (See on see, mida kõik spetsialistid ütlevad, et me peame igal juhul tegema.)
Kui aga tõsiselt rääkida, siis see parandab kvaliteeti, sest kui mitte mingil muul põhjusel midagi katki läheb, näete, milline test ebaõnnestub või isegi kui olete mõnes piirkonnas katteta jäänud.
Ma ei arva mõnede inimeste mõtteviisi, et teil peab olema 100% koodikatvus (ja sellel on põhjused, miks ma seda arvan), kuid ma arvan, et on oluline, et kood kataks võimalikult palju koodi, mis ei ole otseselt seotud. WordPressile.
Koodi testimine WordPressis
Ma ei tea, kas see kõlab segadusse ajav või mitte, kuid üks lõksudest, millesse ma üksuse testimise ja WordPressiga töötades varakult sattusin, oli WordPressi põhikoodi vastu testide kirjutamine.
Ma teen seda mõnikord (ja võite küsida neilt, kellega koos töötan, kas see vastab tõele), kuigi mul läheb see paremaks.
Minu meelest võib WordPressi ennast käsitleda kui musta kasti. See on alus, millel teie rakendus töötab. WordPressi tuuma ümber on juba testid. Kas peaks rohkem olema? Muidugi. Kas see, mis neil on, on piisav? Minu kogemuse kohaselt jah, kuid me kõik kasutame nimetatud funktsioonide erinevat alamhulka.
Mõte, millest ma aru saan, on järgmine: iga kord, kui töötate WordPressile üles ehitatud projektiga; te ei pea kirjutama teste selliste koodide vastu nagu add_menu_pagevõi wp_enqueue_script.
Me teame, et need funktsioonid töötavad.
Selle asemel keskenduge oma domeenile omasele koodile. See tähendab, et keskenduge koodile, mida teie ja teie meeskond kirjutate. See on projektis ainulaadne erialavaldkond ja see on valdkond, mis lõpuks vastutab antud probleemi lahendamise eest.
Kui teie eesmärk on saada 100% katvus ainult 100% katvuse nimel, siis ei kirjuta te ühikuteste õigel põhjusel. Selle asemel püüdke saavutada kõrgeim koodi katvus, mis teie koodi piisavalt testib. See tagab kvaliteedi.