Rusrails ghid pentru testarea aplicațiilor pe șine

Un ghid pentru testarea aplicațiilor pe șine

Acest ghid dezvăluie mecanismele built-in Rails pentru testarea aplicației.

După ce ați citit-o, veți învăța:







  • Despre terminologia de testare Rails.
  • Cum se scriu unități, funcționale, integrare și teste de sistem pentru aplicația dvs.
  • Despre alte metode populare de testare și plug-in-uri.

1. De ce să scrieți teste pentru aplicația dvs. pe șine?

Rails oferă să scrie foarte testele. Când creați modelele și controlorii, începe să creați un schelet al codului de testare.

Running Rails teste vă permite să vă asigurați că codul dvs. aderă la funcționalitatea dorită, chiar și după o remodelare mare a codului.

Testele Rails pot, de asemenea, să simuleze cererile browserului, astfel încât să puteți testa răspunsul aplicației fără a fi nevoie să testați utilizând un browser.

2. Introducere în testare

Suportul de testare este construit în Rails încă de la început. Și nu a fost așa: "Oh, să susținem lansarea testelor, este nou și răcoros!"

2.1. Configurarea rails-urilor pentru testarea de la zero

Rails creează un director de testare de îndată ce creați un proiect Rails folosind șine noi _application_name_. Dacă te uiți la conținutul acestui dosar, vei vedea:

Ajutoarele pentru adrese. mail-urile și modelele sunt destinate să conțină teste pentru asistenți, telespectatori și modele, respectiv. Directorul de controale este destinat să conțină teste pentru controlorii, rutele și vizualizările. Directorul de integrare intenționează să conțină teste pentru interacțiunea dintre controlori.

Luminile reprezintă o modalitate de organizare a datelor de testare; acestea sunt în directorul de fixtures.

Se va crea și directorul de locuri de muncă. imediat ce este generat primul test asociat.

Fișierul test_helper.rb conține configurația implicită pentru testele dvs.

application_system_test_case.rb conține setările implicite pentru testele dvs. de sistem.

2.2. Testați mediul de dezvoltare

În mod implicit, fiecare aplicație de pe Rails are trei medii de dezvoltare: dezvoltare, testare și producție. Baza de date pentru fiecare dintre ele este configurată în config / database.yml.

În mod similar, puteți schimba configurația mediului. În acest caz, puteți schimba mediul de testare schimbând opțiunile în config / environments / test.rb.

Testele dvs. sunt executate cu RAILS_ENV = test.

2.3. Rails se întâlnește cu Minitest

Dacă vă aduceți aminte, am folosit comanda de generare a șinelor în Ghidul Rails Beginner's. Am creat primul nostru model, în care, printre altele, au fost create teste neterminate în dosarul de testare:

Testul implicit în test / models / article_test.rb arată astfel:

Un studiu rapid al acestui fișier vă va ajuta să navigați în codul de testare Rails și terminologia.

Prin solicitarea acestui fișier, configurația implicită a test_helper.rb este încărcată pentru a rula testele noastre. Vom include această linie în toate testele scrise, astfel încât toate metodele adăugate la acest fișier vor fi disponibile în toate testele noastre.

Clasa ArticleTest definește un caz de testare. Deoarece este moștenit de la ActiveSupport :: TestCase. Prin urmare, ArticleTest are toate metodele disponibile în ActiveSupport :: TestCase. Mai târziu, în acest manual, vom vedea câteva dintre metodele pe care ni le oferă.







Orice metodă definită într-o clasă moștenită de la Minitest :: Test (care este o superclasă pentru ActiveSupport :: TestCase), pornind de la test_ (sensibil la minuscule), sună pur și simplu la test. Astfel, metodele definite ca test_password și test_valid_password. acestea sunt numele corect de testare și vor fi lansate automat când începe testul.

Rails adaugă, de asemenea, o metodă de testare. care ia numele testului și blocului. Acesta generează un test de rutină MiniTest :: Unitate cu numele metodei începând cu test_. deci nu trebuie să vă faceți griji cu privire la metodele de numire, ci doar scrieți astfel:

Este cam la fel ca și cum ar fi scris:

Deși puteți utiliza în continuare definițiile obișnuite ale metodei, utilizarea macro-ului de testare vă permite să obțineți un nume de test mai ușor de citit.

Numele metodei este generat prin înlocuirea spațiilor cu subliniere. Deși rezultatul nu trebuie să fie un identificator Ruby valabil, numele poate conține semne de punctuație etc. Acest lucru se datorează faptului că în Ruby tehnic orice șir poate fi un nume de metodă. Acest lucru poate necesita ca apelurile pentru a define_method și trimite funcția corectă, dar oficial există doar o mică restricție asupra numelui.

Apoi, uită-te la prima noastră afirmație:

Afirmația este o linie de cod care calculează un obiect (sau o expresie) pentru rezultatele așteptate. De exemplu, o afirmație poate verifica:

  • această valoare este egală cu valoarea respectivă?
  • este acest obiect nul.
  • Are această linie o excepție?
  • este parola de utilizator mai mare de 5 caractere?

Fiecare test trebuie să conțină una sau mai multe instrucțiuni, fără limite ale numărului maxim. Numai atunci când toate declarațiile au succes, testul trece.

2.3.1. Primul tău test

Pentru a vedea cum eșuează testul, puteți adăuga un test de eroare în cazul testului article_test.rb.

Să executați testul nou adăugat (unde 6 este numărul liniei unde este definit testul).

În consecință, F înseamnă eșec. Puteți vedea următoarea traseu în cazul defecțiunii împreună cu numele testului nereușit. Următoarele rânduri conțin o urmă de stivă, apoi un mesaj, unde se menționează valoarea reală și valoarea așteptată în instrucțiune. Implicit, mesajul de aprobare furnizează suficiente informații pentru a ajuta la identificarea erorii. Pentru a face mesajul de eșec pentru aprobare mai lizibil, fiecare afirmație oferă un parametru opțional pentru mesaj, după cum se arată aici:

Executarea acestui test va arăta un mesaj mai prietenos pentru aprobare:

Acum, pentru ca acest test să treacă, puteți adăuga validarea la nivel de model pentru câmpul de titlu.

Acum testul va trece. Să ne asigurăm acest lucru, executându-l din nou:

Acum, dacă observați, am scris mai întâi un test eșuat pentru funcționalitatea dorită, apoi am scris un cod care adaugă funcționalitate și, în final, ne-am asigurat că testul nostru a trecut. Această abordare a dezvoltării software-ului se numește Dezvoltare prin testare, dezvoltare bazată pe teste (TDD).

2.3.2. Cum arata eroarea

Pentru a vedea cum este raportată eroarea, iată testul care conține eroarea:

Acum veți vedea un rezultat mai mic în consola de a rula testele:

Marca "E" ca rezultat. Ea marchează testul cu o eroare.

Executarea fiecărei metode de testare se oprește imediat ce apar erori sau defecțiuni, iar suita de testare continuă cu următoarea metodă. Toate metodele de test sunt executate în ordine aleatorie. Pentru a configura comanda de test, puteți folosi opțiunea config.active_support.test_order.

Când testul eșuează, vi se afișează backtrack-ul corespunzător. Implicit, Rails filtrează această backtrace și tipărește numai liniile care se aplică aplicației dvs. Acest lucru elimină zgomotul din cadru și vă ajută să vă concentrați asupra codului. Cu toate acestea, există situații în care doriți să vedeți un backtrack complet. Setați argumentul -b (sau --backtrace) pentru a include acest comportament:

Dacă doriți ca acest test să treacă, îl puteți modifica utilizând asert_raises după cum urmează:

Acum trebuie să treacă acest test.

2.4. Aprobări disponibile

Prin acest punct, ați văzut deja câteva dintre afirmațiile disponibile. Aprobările sunt cai de lucru de testare. Ei sunt singurii care efectuează de fapt controale pentru a vă asigura că totul funcționează conform destinației.

Mai jos este un extras din declarațiile pe care le puteți folosi cu Minitest. Biblioteca de testare utilizată de Rails în mod implicit. Opțiunea [msg] este un mesaj șir opțional pe care îl puteți specifica pentru a face mesajul de eroare mai clar.







Trimiteți-le prietenilor: