cum să vă testați aplicațiile Web

în industria software, toată lumea își testează aplicațiile într-un fel. Multe echipe de dezvoltatori au elaborat scheme de testare care sunt bine integrate cu conductele lor de integrare continuă, dar chiar și cei care nu au teste automate trebuie să vină cu modalități de a verifica dacă codul lor funcționează conform destinației.

construirea unui site web și accesarea manuală a acestuia cu ajutorul unui browser este o varietate de teste. Deși nu este cel mai sofisticat, totuși contează. Același lucru este valabil și pentru aprinderea cURL în consolă și trimiterea unei cereri sintetice către punctul final API pe care tocmai l-ați creat.

această postare va discuta despre cum să automatizăm testarea manuală pe care o facem deja înainte de a ne scufunda în diferite tipuri și metodologii de testare.

automatizarea testelor

testele manuale sunt suficiente pentru aplicațiile mici, dar, atunci când aceste aplicații cresc, suprafața lor testabilă crește odată cu ele, provocând două probleme.

unul, atunci când oamenii trebuie să efectueze teste de fiecare dată când o nouă versiune a unei aplicații este terminată, pot apărea inconsecvențe. Acest lucru este valabil mai ales dacă există multe teste. În al doilea rând, persoana care face testele nu poate îndeplini alte sarcini. Cu aplicații mari, testarea ar putea dura mai multe zile.

cel mai logic mod de a rezolva aceste două probleme este automatizarea acestor sarcini manuale. Există două tipuri principale de teste pentru aplicațiile web: teste UI și teste API. Două instrumente le pot automatiza.

testele UI

testele UI pot fi efectuate cu un instrument numit Puppeteer. Puppeteer vă permite să automatizeze un test manual UI folosind JavaScript. Este instalat prin NPM cu următoarea comandă:

 $ npm i puppeteer

puteți scrie apoi un script care controlează o versiune fără cap de Chrome pentru a rula testele. Acest script ar putea arăta astfel:

(async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); await page.goto('https://google.com', {waitUntil: 'networkidle2'}); const heading = await page.$('h1'); await browser.close(); if(!heading) console.log('No heading found!');})();

în acest script, începem o instanță fără cap a Chrome, navigând la example.com, și în căutarea unui element h1. Dacă nu există, este înregistrat un mesaj de eroare.

testele API

testele API pot fi automatizate prin Poștaș. Poștașul vine cu o interfață grafică pentru construirea cererilor HTTP care pot fi salvate. Aceste cereri pot fi executate mai târziu, cu doar un click de mouse.

pentru a începe, descărcați și instalați interfața Poștaș. Următorii pași sunt necesari pentru a crea și salva o solicitare:

1. Faceți clic pe Creați o colecție din stânga
2. introduceți colecția mea ca nume de colecție
3. Faceți clic pe Creare
4. Faceți clic pe elipsa (…) a colecției mele din stânga
5. selectați Adăugare cerere
6. introduceți cererea mea ca nume cerere
7. Faceți clic pe Salvare în colecția mea

cererea apare în bara laterală din stânga sub colecția nou creată.

dacă îl selectați, va trebui să introduceți example.com ca URL și adăugați un test. Pentru a adăuga un test, faceți clic pe teste în bara de file de sub câmpul de introducere a adresei URL.

va apărea o zonă de text în care vă puteți scrie testul în JavaScript. Următorul este un exemplu de test:

pm.test("Status code is 200", () => { pm.response.to.have.status(200);});

dacă faceți clic pe Salvare în colțul din dreapta sus al ecranului și trimiteți imediat după acesta, solicitarea dvs. va fi trimisă. Scriptul de testare se va executa apoi pentru a determina dacă răspunsul a avut sau nu statutul 200.

tipuri de teste

există trei tipuri diferite de teste. Înțelegerea acestora vă permite să alegeți tipul potrivit de testare pentru diferitele părți ale stivei dvs. de software.

testele unitare

testele unitare sunt cel mai simplu tip de test. Ei verifică corectitudinea părților mici ale codului dvs. Un test de unitate acoperă de obicei un apel către o funcție sau o modalitate de a utiliza o clasă.

un test de unitate este de obicei primul “utilizator” al codului dvs. Unele metodologii de testare necesită chiar să scrieți testul înainte de implementarea codului propriu-zis al aplicației.

testele unitare pot fi utilizate atât în dezvoltarea backend, cât și în frontend. Unele echipe de dezvoltare folosesc teste unitare pentru a verifica ieșirea DOM redată a unor părți mici ale codului lor, cum ar fi formulare sau meniuri. În backend, testele unitare sunt adesea folosite pentru a testa codul între serverul HTTP și baza de date sau alte API-uri.

trei alergători de testare utilizate pe scară largă pentru testele unitare sunt:

‐ Jest—Jest este folosit mai ales în dezvoltarea frontend, deoarece vine cu caracteristici unice, cum ar fi testarea instantaneu, care ajuta cu probleme cum ar fi regresii UI. Un tutorial Jest poate fi găsit aici.

‐ AVA—AVA este favorizată în dezvoltarea backend-ului, deoarece este specializată în executarea extrem de paralelă a testelor. Un tutorial AVA poate fi găsit aici.

‐ PHPUnit—PHPUnit este un cadru popular pentru teste unitare în PHP. Un tutorial PHPUnit poate fi găsit aici.

dacă un test de unitate necesită anumite resurse externe, cum ar fi conexiuni de rețea sau baze de date, atunci probabil scrieți un test de integrare. Acest tip de test este acoperit în continuare.

teste de integrare

din perspectiva implementării, testele de integrare arată ca teste unitare. Diferența este că testele de integrare testează mai multe părți ale stivei împreună. De exemplu, ar putea testa dacă clientul și serverul vorbesc sau nu același protocol sau, într-o arhitectură microservices, dacă serviciile funcționează sau nu corect împreună.

verificările care de obicei ar ajunge în mai multe teste unitare independente pot fi agregate într-un singur test de integrare care determină dacă totul funcționează bine împreună.

testele de integrare sunt utilizate atât în dezvoltarea frontend, cât și în backend. Uneori sunt folosite pentru a vedea dacă cele două părți interacționează corect, dar pot fi folosite și pentru a determina dacă diferite module ale unei părți lucrează împreună așa cum se intenționează.

puteți utiliza aceiași alergători de testare pentru testele de integrare pe care le-ați utilizat pentru testele unitare. Cu toate acestea, Postman, instrumentul UI utilizat mai sus pentru automatizarea testelor API manuale, vine și cu un instrument CLI numit Newman care poate fi integrat cu conducta CI/CD.

Newman poate rula colecții poștaș exportate, permițându-vă să creați cereri și teste cu UI poștaș și a le rula mai târziu prin CLI. Un tutorial Newman poate fi găsit aici.

dacă un test de integrare necesită interacțiune cu UI, acesta se numește test UI—adresat în continuare.

testele UI

testele UI sunt cele mai sofisticate teste. Ei încearcă să imite comportamentul utilizatorului într-un mod automat, astfel încât testerii să nu fie nevoiți să facă clic manual pe fiecare parte a aplicației lor.

testele UI ajută adesea la captarea unei interacțiuni specifice care a dus la o eroare pentru un utilizator. Odată ce este capturat, acesta poate fi reprodus cu un singur clic pentru a remedia eroarea și a împiedica revenirea într-o nouă versiune.

alergătorii de testare Jest și AVA menționați anterior pot fi folosiți aici, dar de obicei veți avea nevoie de o bibliotecă suplimentară pentru a facilita interacțiunea UI prin intermediul unui browser. Cele două biblioteci principale utilizate în prezent pentru acest proces sunt:

‐ Puppeteer—Puppeteer este o bibliotecă JavaScript care vine cu o implementare fără cap a Chrome care permite rularea testelor UI programatic în fundal. Un tutorial păpușar poate fi găsit aici.

‐ Selenium—seleniul este un cadru care permite controlul de la distanță al unui browser printr-o bibliotecă numită WebDriver. Un tutorial despre seleniu poate fi găsit aici.

există mai multe tipuri de teste decât cele enumerate aici. Alții pot avea obiective diferite; de exemplu, testele de încărcare încearcă să găsească blocaje de performanță. Rețineți că testele descrise aici primesc uneori nume diferite. Cele trei tipuri prezentate mai sus sunt cele esențiale de implementat atunci când începeți. Folosirea uneia dintre ele este mai bună decât utilizarea deloc a testării automate.

metodologii de testare

metodologii de testare sunt moduri de a gândi despre testare. Cele trei descrise mai jos sunt cele mai frecvent utilizate.

Test Driven Development (TDD)

TDD este cea mai utilizată metodologie și cea mai tehnică. Vă recomandă să scrieți testele înainte de a scrie codul real pe care doriți să îl testați. Deoarece trebuie să scrieți un test doar pentru partea codului pe care îl implementați, tipul de test pe care îl veți scrie este un test unitar.

testele unitare sunt destul de granulare, astfel încât, în timp, utilizarea acestei metodologii are ca rezultat acumularea multor teste. Această realitate, asociată cu faptul că practicienii TDD începători tind să scrie teste banale, poate duce la crearea unei grămezi de teste inutile. Pentru a evita acest lucru, este esențial să actualizați și să curățați testele atunci când echipa s-a familiarizat mai mult cu TDD și cu testarea în general.

este important să rulați testele frecvent, nu numai într-o conductă CI/CD, ci și local pe mașina dvs. de dezvoltare. Scrieți un test, rulați-l, vedeți că eșuează, implementați suficient pentru a trece testul și repetați procesul.

pentru lecturi suplimentare, consultați descrierea Agile Alliance a TDD.

Acceptance Test Driven Development (ATDD)

ATDD este o modificare a TDD care se concentrează mai mult pe cazurile de afaceri și mai puțin pe implementarea tehnică. Tipurile de teste utilizate în această metodologie sunt în mare parte teste de integrare, deoarece, adesea, mai multe părți ale sistemului trebuie utilizate împreună pentru a rezolva o nevoie de afaceri.

deoarece testele sunt mai puțin tehnice, este de asemenea recomandabil să se includă persoane care nu sunt orientate tehnic în procesul de testare. Proprietarii de produse și clienții pot ajuta la definirea cazurilor de afaceri, astfel încât un dezvoltator să poată scrie un test pentru ei. Dacă testul nu poate fi rulat cu succes, este clar că trebuie implementate mai multe funcționalități.

ATDD funcționează la un nivel de abstractizare diferit de TDD, astfel încât cele două metodologii pot fi utilizate împreună.

pentru lecturi suplimentare, consultați descrierea Agile Alliance a TDD.

Behavior Driven Development (BDD)

BDD este un amestec de TDD și ATDD, iar scopul său este de a folosi cele mai bune din ambele lumi pentru a face sistemul global mai stabil. BDD încearcă să specifice un sistem cu teste care ilustrează utilizarea acestuia.

la fel ca ATDD, BDD încearcă să surprindă cazuri de afaceri. Cu toate acestea, vă cere, de asemenea, să puneți la îndoială aceste cazuri de utilizare cu “5 whys”, deoarece “whys” sunt o parte lipsă în ATDD. Sigur, este mai bine să întrebați clienții ce doresc în loc să se bazeze exclusiv pe contribuția dezvoltatorului. Dar, de asemenea, este important să punem la îndoială ipotezele ambelor grupuri.

BDD este, de asemenea, un amestec de TDD și ATDD în sensul nivelurilor de abstractizare. TDD testează doar părțile mici ale aplicației dvs., iar ATDD testează doar modul în care aceste părți funcționează împreună. BDD vă cere să aplicați această metodologie întregii aplicații și părților sale mici, făcând BDD o abordare mai holistică a testării.

pentru lecturi suplimentare, consultați descrierea BDD a Agile Alliance.

concluzie

deși nici o testare nu este teribilă, testarea manuală este mai bună, iar testarea automată este cea mai bună.

în funcție de dimensiunea aplicației dvs., un test manual poate bloca membrii echipei de dezvoltare să lucreze la alte proiecte zile sau chiar săptămâni, costând timpul și banii afacerii dvs. În plus, sarcina monotonă de a efectua aceleași interacțiuni din nou și din nou poate duce la alunecări care se manifestă adesea în bug-uri neîncetate.

computerele sunt foarte bune la repetarea aceleiași sarcini din nou și din nou, deci este o idee bună să delegați testarea unui script și să eliberați timpul dezvoltatorilor. Dacă aceste teste sunt integrate în conducta CI/CD, testele deja scrise pot rula implicit atunci când un nou commit aterizează în depozitele dvs.

este o idee bună să folosiți o metodologie de testare din timp, deoarece, frecvent, marile probleme atunci când începeți sunt “CE” și “când” pentru a testa. Aceste metodologii pot ajuta la clarificarea unui proces care face testele de scriere mai consistente pentru toți membrii echipei.