Share
În ultimul articol, am început să vorbim despre teoria testării unităților în WordPress. Mai precis, am revizuit munca noastră pe teme de testare a unității și plugin-uri, apoi am început să discutăm unitățile de cod, modul în care acest lucru are impact asupra testelor noastre și am analizat testarea unităților în lumea mai largă a dezvoltării de software.
Vom continua să discutăm teoria testării unităților în WordPress, dar vom face acest lucru din perspectiva modului în care poate ajuta la identificarea problemelor, arhitectura, documentarea proiectului și mai mult.
Amintiți-vă de la începutul acestei serii, că modul tradițional de a efectua testarea unității este următorul:
Da, primul pas este un pic dogmatic. De ce să pierdeți minutele care rulează ceva ce știi că va eșua, nu? Totuși, veți obține ideea. Dar, pe măsură ce începeți să aplicați această tehnică specială dezvoltării, veți descoperi că veți dezvolta un anumit ritm de scriere a codului dvs. și că acesta face parte din întregul obiectiv.
Dar asta este doar jumătate din ea - testarea unității poate ajuta de fapt să detectezi probleme mai devreme în dezvoltare.
Pentru a înțelege acest lucru, probabil că este bine să vă întoarceți la idee.
Să presupunem că lucrați la o caracteristică pentru un proiect bazat pe WordPress, în care veți permite utilizatorilor să creeze un cont de utilizator fără a se autentifica în tabloul de bord WordPress. Aceasta presupune că aveți o setare a șablonului de pagină pentru a gestiona înregistrarea, validarea necesară în vigoare și codul pentru generarea de parole și e-mailuri.
Încărcați pagina în browserul dvs., încercați să creați câțiva utilizatori - unele cu aceeași adresă de e-mail, unele cu parole necorespunzătoare, altele cu caractere ilegale etc. Obțineți punctul - există mai multe moduri de validare să treacă și să nu reușească. Acest lucru este dur! Aceasta înseamnă că de fiecare dată când funcția de înregistrare a utilizatorului este schimbată, trebuie să efectuați același număr de n-numere de înregistrări pentru a vă asigura că nimic nu este rupt.
Sau puteți scrie o serie de teste pentru a avea grijă de ele și a le rula de fiecare dată când codul se schimbă.
Deci, da, testarea unităților de scriere poate dura mult timp în față, dar uitați-vă la timpul salvat de fiecare dată când modificați o unitate de cod. Este bine meritat și acest lucru poate ajuta la identificarea problemelor din timp - adică înainte de a fi lansat în producție - care ar fi putut fi ratat pentru că cineva a uitat să simuleze o permutare a testului.
Când vine vorba de scrierea testelor de unitate, nu numai că îmbunătățiți calitatea codului, asigurându-vă că funcționează, dar vă furnizați în mod inerent o documentație orientată spre dezvoltatori.
Dacă testați unitatea funcționalitățile pe care le construiți în produsul dvs., veți furniza documentația pentru modul în care funcțiile sunt destinate să funcționeze, când acestea ar eșua și când ar trebui să treacă.
Există câteva presupuneri care vin cu acest lucru: Mai precis, că numiți logic și grupați funcțiile și testele asociate și că testați în mod corespunzător fiecare funcție.
Prin intermediul PHPUnit, Testele Unității WordPress facilitează realizarea afirmațiilor ușor de citit. Numai afirmați assertTrue, assertFalse sau orice alte afirmații disponibile cu privire la funcțiile care vă compun proiectul.
Urmând exemplul nostru de mai sus, aceasta înseamnă că puteți scrie o funcție pentru a vă asigura că funcția de înregistrare a utilizatorului nu reușește atunci când încercați să vă înregistrați cu o adresă de e-mail gol:
Accentsconagua
$ this-> assertFalse (registerNewUser (")); Un exemplu simplu, poate, dar punctul rămâne: Codul dvs. devine auto-documentare și necesită doar să scrieți teste unitare clare.
Poate că unul dintre cele mai subevaluate avantaje ale testării unității este că poate ajuta la conducerea arhitecturii proiectului dvs. De obicei, dezvoltarea temelor sau pluginurilor poate porni unul din cele două moduri:
Acestea nu sunt în mod inerent rele, dar cred că sunt slabe (și voi fi primul care va recunoaște că am făcut mai mult decât am vrea să împărtășesc!). Dar pasul "scrie codul" presupune mult, nu-i așa??
Pentru oricine a scris cod pentru o cantitate suficientă de timp, sunteți prea familiari că ajungeți să atingeți punctul în care vă dați seama: "Oh ... nu m-am gândit la asta".
Dacă aveți noroc, aceasta înseamnă, de obicei, că puteți scrie o metodă de ajutor sau o altă condiție care să se ocupe de cazul pe care l-ați neglijat, dar în cele mai grave cazuri, înseamnă că va trebui să refaceți întreaga clasă sau întregul set de funcții adaptați această problemă.
Unitatea de testare, deși nu este perfectă, poate ajuta la atenuarea acestui lucru.
Luați în considerare faptul că, de la bun început, listați toate funcționalitățile pe care doriți să le oferiți tema sau pluginul dvs. Aveți încă de scris orice cod, dar poate aveți un tip de schiță a interfeței UI și / sau un set de diagrame de clasă.
Apoi, începeți să scrieți testele pe care urmează să le scrieți pentru a vă testa proiectul. Amintiți-vă că o parte din testarea unității este de rupere a codului la cea mai mare unitate atomică posibil, astfel încât sunteți însărcinat cu scris teste unitate pentru fiecare dintre aceste, hm, Unități.
Din cauza naturii testelor de unitate, te gândești în mod inerent la codul tău diferit: mai degrabă decât "scrie cod", te gândești "scrie teste" și pentru că trebuie să te gândești la un nivel mai atomic, poți nu ajutați, dar luați în considerare cazurile marginale care sunt atât de des incluse în "codul de scriere".
În calitate de dezvoltatori, suntem mult prea confortabili în utilizarea convențiilor care întăresc continuu că scriem coduri. Prin aceasta, vreau să spun că avem tendința de a furniza nume variabile abreviate, nume de funcții criptice și nume de clasă care nu înseamnă nimic pentru nimeni în afara dvs. sau a echipei care lucrează la proiectul dvs..
Testarea unităților nu este neapărat cheia pentru scrierea unui cod care este mai ușor de citit, dar poate merge mai departe în a ajuta la furnizarea unor nume de funcții mai curate.
Amintiți-vă din prima carte de programare pe care ați citit-o, prima clasă de informatică pe care ați luat-o sau prima piesă de cod sursă pe care ați văzut-o, numele de metode sunt de obicei verbe. De ce nu ar trebui să fie? Metodele sunt modalități de încapsulare a codului face lucruri. Dar, pe măsură ce lucrăm la proiecte mai lungi și mai lungi, ajungem la lazier și lazier și codul nostru merge de la "register_user_and_email_password ()" la "cont nou()".
Evident, prima este mai curată decât cea din urmă, dar dacă ne străduim să încercăm unitatea de calitate și vrem să ne asigurăm că testele unității noastre sunt ușor de citit și pentru a fi ușor de citit, numele funcțiilor noastre trebuie să fie ușor de citit.
Nu este mai ușor de citit:
$ this-> assertFalse (registrul_user_și_email_password (")); In loc de asta?
$ this-> assertFalse (new_account (")); Din nou, poate acesta este un exemplu simplu, dar principiul rămâne: Scrierea unor teste de unitate bune pentru a ajuta la auto-documentarea codului care conduce limba funcțiilor dvs..
Am vorbit despre elementele de bază ale testării unităților, precum și despre avantajele cheie, dar nu am discutat încă dezavantajele care vin cu testarea unităților și nici măcar nu am analizat cum să le integrăm în fluxul nostru de lucru.
Astfel, în următorul articol, vom încerca să facem acest lucru.
