Share
Ne-am uitat la testarea unităților pentru dezvoltarea WordPress. Prin utilizarea exemplelor practice, am analizat modul de testare a unităților care arată atât pentru pluginuri, cât și pentru teme; cu toate acestea, nu am vorbit cu adevărat despre teoria din spatele testării unității.
Asta înseamnă că nu am luat o privire la nivel înalt la ceea ce este, de ce este benefic și cum îl putem încorpora în fluxul nostru de lucru. În următoarea serie de articole, vom defini unitatea de testare, vom acoperi beneficiile sale principale, de ce ar trebui să ne deranjeze să o facem și o parte din resursele pe care le vom folosi în munca noastră.
Deși nu există cod pentru a lucra pentru acest tutorial special, ar trebui să ofere o bază solidă pe care aplicarea practică a articolelor anterioare se bazează.
Înainte de scufundări în articol, cred că este important să luăm în considerare motivele pentru care ar trebui să te deranjezi de testare și pluginuri la toate.
Până de curând, WordPress a fost văzută în primul rând ca o platformă de blogging și ca un sistem de management al conținutului. Ea le face pe amândouă foarte dar, pe măsură ce dezvoltatorii își descoperă API-ul bogat, devine din ce în ce mai popular să construiști anumite tipuri de aplicații folosind WordPress ca platformă de bază.
În plus, temele sunt mai mult decât piei pentru un site web - sunt mai mult decât o foaie de stil și câteva fișiere șablon pentru afișarea datelor. De fapt, acum, poate mai mult ca niciodată, echipele întregi dedică timp (și chiar își fac viața) de a crea teme pentru WordPress. Deci, nu lăsați cuvântul "temă" să vă ghicească - temele sunt ca aplicații pentru WordPress. Ele adaugă funcționalitate, pre-procesează și post-procesează date și introduc adesea funcționalități semnificative în WordPress, dincolo de simpla oferire site-ului dvs. a facelift.
În cele din urmă, plugin-urile sunt aproape mai multe aplicații ca în natură decât teme. Luați în considerare acest lucru: pluginurile extind nucleul WordPress și deseori funcționează independent de teme. În schimb, ele adaugă noi caracteristici în centrul WordPress, din care pot beneficia toate temele.
Spun toate acestea pentru a da o perspectivă asupra motivului pentru care testarea unității - așa cum o să descoperim - se poate plăti de multe ori, având în vedere că este folosită în contextul unor teme și pluginuri mai complexe.
Am menționat pe scurt acest lucru în primul articol din serie. Nu vreau să ofer o revizuire totală a ceea ce a fost deja scris, așa că voi rezuma punctele de aici:
Dar asta e doar zgârierea suprafeței.
Pentru a înțelege cu adevărat unitățile din tema sau plugin-ul dvs., trebuie să vă gândiți la ceea ce compune o temă. De obicei, este o combinație de:
Deși există cadre de testare unitate special pentru JavaScript, vom fi concentrat mai mult pe aspectul PHP al dezvoltării WordPress. La urma urmei, dacă nu era vorba de funcționalitatea de pe server, în WordPress ar fi fost introdusă foarte puțină funcționalitate unică.
Cu asta am spus că există mai multe moduri de a defini o unitate, dar aș paria că majoritatea oamenilor definesc o unitate ca o funcție. În cea mai mare parte, este corect, dar nu înseamnă că funcțiile noastre sunt cele mai optime unități de testat. De exemplu, funcțiile sunt adesea compuse din mai multe blocuri - probabil bucle, probabil condiționate sau, probabil, apeluri către alte funcții.
Indiferent de situație, există adesea unități mai mici de funcționalitate cuprinse în metode.
Deci, este cu adevărat corect să spunem că testarea unității implică testarea fiecărei funcții care constituie o temă? Nu chiar. Deoarece un singur bloc de cod - sau, în unele cazuri, o singură declarație - este responsabil pentru realizarea unei sarcini specifice, aceste ar face adevărate unități de cod.
Și dacă ar trebui să scriem teste unitare, cum să scriem teste pentru unitățile care există în cadrul funcțiilor noastre?
Reamintim că mai devreme în serie, am spus:
Aici apare una dintre cele mai mari schimbări ale codului de testare unitate scrisă: eliminați unitățile de funcționalitate în cea mai mică piesă atomică posibilă. Sigur, acest lucru duce adesea la un număr mare de funcții foarte mici, dar este un lucru rău?
În acest sens, fiecare funcție are cu adevărat un singur scop. Și presupunând că funcția dvs. face un singur lucru, există doar atât de multe moduri de a numi funcția care poate duce la codul mult mai ușor de citit.
Desigur, există un compromis deoarece puteți introduce câteva linii de cod în timp ce scrieți aceste funcții suplimentare, dar atunci când lucrați la un produs cu o echipă de alte persoane care va fi folosit de mii de clienți, trebuie să vă întrebați dacă codul suplimentar este în valoare de calitatea pe care o puteți obține în testarea corectă a muncii dvs. A terminat corect, echipa ta ar trebui să să poată urma mai ușor logica codului și produsul va avea un nivel de calitate care este adesea dificil de realizat fără testarea unității de scriere.
Un lucru esențial de a recunoaște testele unității este că nu depind unul de celălalt. Un test de unitate unică ar trebui să testeze un singur lucru. În plus, aceasta înseamnă că un test unic ar trebui să includă într-adevăr o singură afirmație (dar există excepții care sunt demonstrate aici).
Amintiți-vă: Scopul testului unității este de a evalua calitatea unei singure unități de cod. Unele unități vor accepta argumente, unele unități nu vor, unele unități vor returna valori, altele nu vor. Indiferent de situație, testul unității trebuie să evalueze toate cazurile. O singură unitate de cod va avea rar un singur test.
În schimb, aș spune că o regulă bună este că numărul de teste asociate unei unități de cod scară exponențial pe baza numărului de intrări pe care le acceptă.
De exemplu:
Are sens? Cheia de a lua aici este că veți avea în mod semnificativ mai multe teste decât există unități; nu există un raport 1: 1.
În cele din urmă, atunci când efectuați testarea unităților, veți vedea adesea cuvântul "suite de testare" sau "suită" utilizat când discutați testele. Acest lucru poate varia în funcție de contextul în care se efectuează testarea; cu toate acestea, atunci când lucrați cu WordPress, aceasta se referă de obicei la o colecție de teste unitare.
Deci, să spunem că aveți un fișier care este responsabil pentru testarea tuturor funcționalităților legate de scrierea și publicarea unei postări - acest fișier ar fi suita de testare pentru postări. Destul de ușor, nu? Este important să înțelegeți această terminologie dacă întâlniți acest lucru în lectură suplimentară, deoarece poate fi ușor diferită dacă lucrați în, de exemplu, Rails sau .NET.
În cele din urmă, testarea unităților nu este o metodologie nouă și nu este strict limitată la PHP. De fapt, testarea unitară (sau dezvoltarea testată ca un întreg) a fost în jur de peste un deceniu.
Puteți găsi cadre de testare a unităților pentru Java, .NET, Rails, PHPUnit (evident) și așa mai departe.
Dar adoptarea ei a fost amestecată - unii oameni trăiesc și mor prin ea, alții o urăsc și apoi sunt aceia dintre noi care încearcă să înceapă, dar trebuie să echilibreze aplicația practică de ao aduce într-un proiect existent și de a înțelege cantitatea de refactorizări poate fi necesară.
În ceea ce privește teoria, doar începem.
În următorul articol, vom examina în special beneficiile cheie ale testării unităților și modul în care acestea pot fi plătite în dezvoltarea noastră bazată pe WordPress. Vom examina, de asemenea, avantajele pe care testarea unității le aduce arhitecturii, designului și documentației.
Desigur, testul unitar nu este fără dezavantajele lui, așa că vom examina și acelea.
Accentsconagua