Share
În ultimele două articole, am analizat cu atenție teoria din spatele testării unității și modul în care ne poate ajuta în eforturile noastre de dezvoltare WordPress. Am definit testarea unitară și am examinat diferite modalități prin care ne poate ajuta pe parcursul proiectelor noastre.
Dar mai avem încă multe de acoperit.
În acest articol final, vom examina de ce ar trebui chiar să ne deranjăm să efectuăm testarea unitară și vom rezuma avantajele și dezavantajele acestei acțiuni. Apoi, vom examina modul în care putem efectua testarea în proiectele existente. Și pentru a încheia, vom rezuma o listă de resurse care sunt disponibile în mod special dezvoltatorilor noștri WordPress care vor ajuta la începutul unității de testare a temelor noastre.
Tema principală a întregii serii a fost aceea de a ne deranja testarea unitară, dar dacă nu a fost formulată în mod succint, de aceea:
Testarea unităților ne ajută să descoperim problemele devreme, să oferim dezvoltatorilor un nivel de cod de auto-documentare și ne oferă un nivel mai ridicat al calității software-ului.
Acordat, acest lucru presupune că vom urmări practica bunei tehnici de testare a unităților. Desigur, acest lucru a fost acoperit cu mare detaliu în articolul precedent, dar merită reiterat.
Un lucru important de observat - mai ales dacă încercați să aplicați acest lucru într-un context mai corporativ sau în contextul unei afaceri mai mari - este că testarea unităților nu este doar un lucru pe care dezvoltatorii îl fac pentru ei înșiși. Calitatea este bidirecțională - beneficiază clientul și aduce beneficii afacerii.
Prin furnizarea unui nivel mai înalt de calitate pentru client - adică, un software mai bine testat - ar trebui să aibă mai puține bug-uri. Deoarece bug-urile au ca rezultat în timp că dezvoltatorii trebuie să cheltuiască rezolvarea, mai degrabă decât să lucreze la noi proiecte sau noi caracteristici ale produselor existente, acest lucru poate economisi bani.
Prin oferirea unui nivel mai înalt de calitate pentru afacere, dezvoltatorii sunt mai încrezători în eforturile lor, deoarece pot executa o serie de teste de fiecare dată când se face o schimbare, cunoscând modul în care lucrările lor au afectat întreaga aplicație. Dacă un test nu reușește, atunci sunt capabili să-l rezolve înainte de a-l utiliza în producție.
Testarea unității este legată de calitate și afectează nu numai cei care scriu codul, ci și compania care o trimite, precum și clienții care o utilizează.
Adevărul este că am acoperit deja avantajele testării unităților. Pentru completare, să le rezumăm aici (deși le puteți examina întotdeauna în detaliu!). Testarea unităților ...
Sună bine, nu? Și, da, dezvoltatorii se bazează pe responsabilitatea față de standardele și practicile înalte atunci când este vorba despre implementarea efectivă a acestora în activitatea zilnică, dar testarea unitară nu este fără dezavantajele sale.
Acest lucru a fost spus în întreaga serie: testarea unității ia o investiție semnificativă în timp. Desigur, dacă începeți un nou proiect, investiția în timp este mult mai mică decât dacă o potriviți într-o aplicație existentă, dar sunteți încă trebuie să scrie mai mult cod decât fără testare.
Deoarece scrieți mai multe coduri, veți lua mai mult timp - din nou, în partea din față a proiectului. Beneficiile testelor de unitate nu vin până târziu, dar dacă un proiect are o dată specifică pentru lansare și această lansare include un anumit număr de caracteristici, este puțin probabil să se potrivească toate testele și caracteristicile unității în eliberarea.
Dacă doriți să evitați seturile de caracteristici mai mici la datele de lansare sau întârziate, vă avea pentru a construi în timp pentru testarea unității.
Le-ați auzit pe toate: complexitatea ucide, păstrați-o prost prost, mai puțin este mai mult și așa mai departe.
Sincer, toate acestea sunt adevărate și au locul lor de dezvoltare, dar este faptul că testarea unității este cod suplimentar și cod suplimentar mereu introduce mai multă complexitate. Ca atare, trebuie să ne asigurăm că avem o modalitate adecvată de a gestiona și de a organiza toate testele unității noastre.
Poate că este vorba de organizarea fișierelor, de spațierea denumirilor sau de convențiile de numire sau de testele variate sau toate cele de mai sus. Oricare ar fi faptul că faceți acest lucru, testele unitare nu ar trebui să fie tratate ca cetățeni de clasa a doua în lumea software-ului - ar trebui să fie supuși acelorași principii de proiectare ca și alte clase sau funcții cât mai mult posibil.
Da, în ultimul articol am spus că unitatea de testare poate ajuta la proiectarea unei aplicații și poate ajuta la promovarea unui design care face ca întreaga aplicație să fie mai probabilă. Acest lucru este încă adevărat, dar este o cheltuială: uneori, designul cel mai unitar testabil nu este cel mai clar.
Prin aceasta, vreau să spun că deoarece un set de funcții - sau chiar o clasă - este testat pe deplin pe unitate, coeziunea are potențialul de a fi compromisă deoarece facem sacrificii pentru a accesa anumite funcții pentru a verifica prelucrarea datelor. Desigur, aceasta nu este o regulă tare și rapidă și acest lucru poate să nu fie chiar o problemă pentru unii, dar trebuie să decideți ce veți fi dogmatici: este un set perfect de inginerie pentru clase și funcții sau un sistem contiguu de teste și funcții care lucrează împreună?
În cele din urmă, cred că este vorba despre cum vedeți testele ca o parte mai mare a întregului. Dacă acestea fac parte din designul aplicației dvs., atunci designul ar putea să nu sufere. Dar dacă vedeți testele ca o idee ulterioară, atunci proiectarea aplicației de bază poate fi compromisă doar ușor.
După cum se spune, software-ul nu se face niciodată și deoarece testarea unității face parte dintr-o bucată de software, nu se face niciodată.
Deoarece o aplicație va fi mereu în evoluție - fie că este vorba de bug-uri, dar și de noi funcții introduse (sau chiar eliminate), testele asociate vor trebui adăugate sau actualizate. Și întotdeauna vine înapoi la timp.
Mai mult, dacă lucrați într-o echipă de dezvoltatori, lipsa noastră de teste de actualizare poate afecta negativ echipa, deoarece rezultatele pe care testele le pot prezenta pot fi fals pozitive sau negative false. După scrierea testelor, este imperativ ca acestea să fie actualizate; în caz contrar, acestea pot duce la un produs foarte sărac.
Unitatea de testare este o vânzare mai ușoară atunci când începeți cu un proiect, dar dacă doriți să o reconfigurați într-o aplicație existentă (sau temă sau plugin, în cazul nostru), va dura ceva timp și efort.
Și deși nu există un glonț de argint pentru modul în care puteți executa perfect acest lucru, există câteva modalități bune de a începe să aplicați practica în activitatea dvs. zilnică:
Dacă urmați pașii de mai sus, veți ajunge în final la o acoperire semnificativă a codului. Da, este nevoie de timp și da, probabil că va trebui să refaceți o mulțime de cod, dar în același timp investiția va da dividende în viitorul produsului dvs..
Iată un rezumat al resurselor care pot contribui la testarea cu succes a proiectelor bazate pe WordPress:
Între prima serie de articole și această serie de articole a fost pusă o temelie solidă pe care puteți continua să vă construiți practicile de testare a unităților.
Accentsconagua