În prima parte, am stabilit mediul de dezvoltare, am aplicat mai multe reguli luate de la Liga PHP. și a creat două clase simple, dar inutile - Diffbot și DiffbotException. În această parte, vom aborda testul de dezvoltare (TDD)
Dacă doriți să continuați - citiți prima parte a articolului. sau îndoiți depozitul cu exemplul de cod.
Poate că ați auzit deja ceva despre PHPUnit, dar acum este momentul să-l aplicați în practică. Primul pas este să verifici dacă acesta este instalat:
Rularea acestei comenzi ar trebui să ofere informații cu un raport despre un test trecut. Acesta este un test care vine în mod implicit cu o aplicație de probă și, de fapt, testează afirmația că adevărul este adevărat. Raportul de acoperire va fi, de asemenea, generat și plasat în directorul proiectului.
Dacă deschideți acest raport de acoperire în browser, ar trebui să vedeți că procentul de acoperire al proiectului nostru este foarte mic.
Acum, că suntem convinși că PHPUnit lucrează pentru noi, să încercăm ceva. În prezent, nu avem mult cod în afară de getters și setters, care, în general, nu ar trebui să fie testate. Deci, ce putem testa în codul nostru actual? Ei bine ... Ce se întâmplă cu valabilitatea tokenului trecut când creați instanța obiectului?
Mai întâi, aruncați o privire la fișierul de configurare PHPUnit, phpunit.xml.dist. După ce schimbăm cuvântul "Liga" în "Diffbot" ar trebui să arate astfel:
Atributele elementul principal al PHPUnit spun că raportul său ar trebui să fie cât mai detaliate posibil, este necesar pentru a converti toate tipurile de avertismente și erori în excepția, și cu restul setărilor pe care le puteți găsi în PHPUnit documentația. Apoi, definim seturile de testare care se aplică aplicației sau scriptului specificat. Un astfel de kit - stabilit pentru aplicația principală (singura pe care o vom folosi), și ne-a numit „Diffbot TESAT Suite“, determinarea că directorul testelor conține toate testele noastre - este posibil să observați că testul de probă al Ligii este deja în acest director. De asemenea, îi spunem PHPUnit că ar trebui să ignore fișierele din directorul src /. deoarece doar vrem să facem teste, nu clasele noastre. Și, în sfârșit, am stabilit logarea - ce, unde și cum este inclus în raport.
Să scriem primul nostru test. În directorul de teste, creați fișierul DiffbotTest.php. Dacă utilizați PhpStorm - acest proces este aproape automat:
Nu uitați să verificați dacă spațiul de nume din fișierul composer.json corespunde cu acesta:
Acum puteți șterge exemplul ExampleTest (precum și clasa SkeletonClass) și înlocuiți conținutul clasei DiffbotTest cu următoarele:
În acest exemplu simplu, testăm metoda statică Diffbot :: setToken. Utilizăm sintaxa datelor furnizoare de date pentru testarea ciclică a seturilor de date. Acest lucru ne permite, de asemenea, să știm ce chei nu sunt valide, în loc să verificăm o aruncare excepțională. Dacă acum conducem testul și ne uităm la copertă, atunci ar trebui să vedem ceva de genul:
Văd realizarea, iar în mine dorința de a vedea cât mai mult posibil se trezeste verde. Să testați crearea unui exemplu de clasă.
Aceste metode acoperă toate cazurile din constructor - instanțierea fără un simbol și fără a fi instalate la nivel global, instanțierea cu un token instalat global și instanțierea numai prin parametru. Dar executând testul, vedem că se termină cu o eroare. Acest lucru se datorează faptului că clasa Diffbot deține încă proprietatea statică setată în testul anterior, prin urmare, nu avem tokenul static în al doilea test în mod implicit. Aceasta este o problemă obișnuită de testare a proprietăților globale și statice. Pentru a lucra în jurul acesteia, vom face fiecare test în clasa DiffbotTest să ruleze într-un proces separat. Acest lucru va încetini punerea în aplicare, dar vom fi siguri că pentru fiecare caz avem un mediu curat și nesălat.
Acum, când executați testul, uitați-vă la copertă - veți vedea că totul a devenit verde!
De fapt, acesta este un fel de anti-model - necesitatea de a rula teste în diferite procese - care, de obicei, indică faptul că clasa de arhitectură este ceva greșit, dar am găsit încă cea mai bună abordare pentru testarea în acest caz. Proprietatea statică din clasa Diffbot trebuie să fie variabilă pentru a fi ușor de utilizat. Dacă aveți sugestii, cum se poate îmbunătăți acest lucru - sunt toată atenția. O abordare alternativă pentru rezolvarea acestei probleme este crearea unei metode de resetare. sau un setter opțional, care poate fi folosit pentru a reveni mana-clasa la starea inițială, dar eu stau departe de astfel de abordări, astfel încât să nu dezordona claselor logice, concepute pentru a testa. De fapt, acest lucru poate fi rezolvat cu ajutorul backupStaticAttributes. dar nu am reușit să reușesc.
TDD (Dezvoltare prin testare)
În TDD, primul lucru pe care trebuie să-l faceți este să vă gândiți la funcționalitatea planificată, apoi să scrieți teste pentru aceasta (să le executați și să obțineți erori) și apoi să implementați funcționalitatea funcțională pentru a executa testele după cum este necesar. În acest caz, testarea controlează dezvoltarea, adică dezvoltarea prin testare. Acesta este exact ceea ce vom face în această secțiune.
Diffbot, ca serviciu, oferă în mod implicit mai multe API-uri:
Conform documentației, fiecare API returnează un răspuns similar (toate returnează un JSON valid), dar setul de câmpuri returnate este de obicei diferit. Acesta este modul în care văd clasa Diffbot în stadiul final al produsului: dispune de metode de accesare a fiecărui tip de API, iar fiecare tip de API este o clasă separată pe care trebuie să o dezvoltăm. Toate clasele API sunt moștenite dintr-o clasă API abstractă care conține un set de settere pentru câmpurile obișnuite și fiecare clasă API adaugă propriile câmpuri personalizate. În general, în general, vreau să obțin o posibilitate similară de a utiliza:
Testarea claselor abstracte
Am definit mai mulți furnizori de date, ca și în primul test. Avem, de asemenea, o metodă care creează obiectul mock, astfel încât să îl putem numi dacă este necesar. Apoi vom crea o metodă de testare pentru toate scripturile - nu există nici un argument timeout, o valoare de argument nevalidă și valoarea corectă a argumentului. Așteptăm o excepție numai dacă argumentul nu este valid.
Dacă executăm testul, atunci primim eroarea:
Rularea testului generează o nouă eroare:
Wow! Am rupt PHPUnit! De fapt, glumesc, e în regulă. Se spune că în clasa noastră nu există o metodă setTimeout (). care este nevoie de test - se presupune că ar trebui să fie la obiectul mock. Să facem schimbări în Api.php.
Repornirea testului va avea ca rezultat:
Acum avem undeva. Acum adăugați implementarea finală a funcționalității de care avem nevoie. Editați corpul metodei setTimeout astfel:
Împreună cu logica, am adăugat un bloc de documentare și a forțat metoda să returneze o instanță a clasei folosite, astfel încât să putem compila un lanț de metode. Reporniți testele, toate trebuie să treacă. Privind la capac ar trebui să vezi 100%.
concluzie
În a doua parte, am început să ne familiarizăm cu TDD cu introducerea PHPUnit și să o folosim pentru a dezvolta o parte din funcționalitatea pachetului nostru. Puteți descărca codul complet al celei de-a doua părți a articolului din această ramură. În următoarea parte, vom continua să dezvoltăm pachetul folosind metodele descrise în acest articol și, de asemenea, vom adăuga un aspect suplimentar - înlocuirea datelor. Nu comuta!
Ultimele 5 lecții din rubrica "PHP"
Când vine vorba de securitatea unui site web, expresia "filtra totul, ecran totul" va fi întotdeauna relevantă. Astăzi, să vorbim despre filtrarea datelor.
Expressive 2 acceptă posibilitatea conectării altor componente ZF pe un circuit special. Nu toată lumea îi place această decizie. În acest articol, vom descrie modul de îmbunătățire a procesului de conectare a mai multor module.
Să presupunem că trebuie să trimiteți câteva informații în Google Analytics din scriptul de pe server. Cum se face. Răspunsul este în această notă.
O selecție de mai multe tipuri de nisip PHP. Pe unele veți putea să vă puneți codul online, dar există și soluții pe care le puteți implementa pe site-ul dvs.
Prin obținerea de informații imediat prin două canale (vedere și auz), eficiența predării este mult mai mare decât învățarea din cărți. Și temele și testele online vă vor permite să gândiți în mod constant în limba pe care o învățați și să vă verificați imediat cunoștințele!
Dacă doriți să învățați HTML mult timp, atunci am o veste bună pentru dvs.!
Dacă ați învățat deja HTML și doriți să treceți mai departe, următorul pas este să învățați tehnologia CSS.
Dacă doriți să înțeleagă conceptele de domeniu si hosting, învață cum să creeze o bază de date, încărca fișiere pe un site web prin intermediul unui server FTP, crea subdomenii, configurați cutiile poștale pentru site-ul și să monitorizeze participarea, acest curs este conceput special pentru tine!