ABONAMENTE VIDEO REDACȚIA
RO
EN
×
▼ LISTĂ EDIȚII ▼
Numărul 81
Abonament PDF

Aplicații practice în testarea automată pentru Behavioral-Driven Development

Radu Cristian Pop
QA Team Lead @ Cognizant Softvision
TESTARE


BDD sau behaviour-driven development (dezvoltare bazată pe comportament), este o metodă de dezvoltare software bazată pe TDD (test-driven development sau dezvoltare bazată pe testare). Se concentrează în principal pe gestionarea procesului de dezvoltare software atât din perspectiva business cât și cea tehnică. BDD încearcă să elimine ceea ce se numește "costul traducerii" - ceea ce spune partea de business și ceea ce înțelege persoana tehnică. Cu BDD, acest lucru ar trebui să fie mult mai clar. BDD este implementat printr-un DSL (domain-specific language) simplu, folosind propoziții clare și concise în limba engleză care exprimă comportamentul și rezultatul așteptat. Inițiatorul BDD este Dan North în 2006.

Exemplu:

Cucumber și Gherkin

Cucumber oferă un limbaj ușor de folosit numit Gherkin. Gherkin folosește o sintaxă simplă foarte asemănătoare cu limba engleză, cu posibilitatea de a utiliza variabile. Fiecare afirmație din Gherkin este precedată de cuvintele-cheie Given-When-Then. Acestea sunt acolo mai ales din punct de vedere gramatical, indicând totodată modul în care urmează să fie utilizat acest pas:

Există, de asemenea, And (si) si But(dar); acestea sunt doar pentru a defini precondiții / acțiuni / așteptări mai complexe. Toate aceste cuvinte cheie sunt, din punct de vedere tehnic, interschimbabile. Odată ce un pas este definit cu unul dintre acestea, poate fi refolosit cu oricare altul și va face același lucru. O altă caracteristică foarte utilă a limbajului Gherkin este faptul că suportă variabilele.

De exemplu:

Când mă conectez cu utilizatorul "johnsmith@someemail.com"
Și introduc parola "secretPassword";

Numele de utilizator și parola sunt variabile aici. Când reutilizăm pasul, putem trimite în orice altă valoare dorim.

Toate cele de mai sus sunt doar fraze în limba engleză, nu fac nimic de la sine. Toate trebuie să fie implementate folosind un limbaj de programare și, probabil, anumite librării, în funcție de ceea ce doriți să faceți.

Testare automată

Ușurința în utilizare și înțelegere

Paradigma BDD este mult mai complexă decât felul în care am utilizat-o noi, dar am valorificat-o în modul în care ne-a avantajat cel mai mult. Cea mai importantă caracteristică a BDD este sintaxa ei asemănătoare englezei, pe care oricine o poate înțelege. Oamenii mai puțin tehnici au apreciat-o pentru că își puteau scrie testele în limba engleză utilizând dicționarul nostru de pași, baza de date și aplicația pe care am dezvoltat-o. De fiecare dată când au fost adăugate funcționalități noi în aplicație, am făcut pași noi pentru acestea, reușind de cele mai multe ori să refolosim pașii vechi cu foarte puțin cod nou. Același lucru a fost și în cazul oricăror solicitări venite din partea unor persoane non-tehnice: "Aș vrea să fac asta. Nu văd niciun pas care să se ocupe de asta. L-ați putea crea? "

Funcționalitate comună între diferiți clienți

Unul dintre lucrurile pe care frameworkul nostru a vrut să le facă este să aibă abilitatea de a scrie teste care să fie agnostice de platformă. În cazul nostru, cei trei clienți - web, android și iOS. Am vrut să oferim utilizatorilor posibilitatea de a scrie un test și de a le rula pe toți cei trei clienți, dacă acel scenariu testează o funcționalitate comună celor trei clienți.

Să presupunem că facem niște teste negative privind autentificarea în aplicație. Toți trei clienții au funcția de autentificare, am scris pașii astfel încât să fie utilizabili pe orice platformă. Desigur, acest lucru nu este atât de ușor de făcut în spatele cortinei, când trebuia să implementăm acești pași, iOS utilizează o librărie, Android alta, iar platforma web, o a treia librărie pentru a interacționa cu fiecare client în parte. În plus, au fost scrise în diferite limbaje de programare - Java și Ruby. Deci, nivelul de integrare dintre acești trei clienți era la nivelul de sus, unde toți trei aveau un singur lucru în comun - limbajul Gherkin. În Gherkin, totul arată la fel, indiferent de limbajul pe care îl avem în spatele lui sau de ce librării folosim. "Given I am logged in", de exemplu, nu face nici o mențiune despre un limbaj de programare și nici o cerință specifică a librăriei folosite, ci doar loghează utilizatorul în aplicație.

Avantaje

Timpul necesar dezvoltării unui framework de la acest nivel

Acest lucru este greu de estimat și variază în funcție de fiecare proiect. Ceea ce putem spune este ca, indiferent de cât de mult ține, acest timp va fi recuperat mai târziu când vine vorba de mentenanță și scalabilitate. În cazul nostru, am avut nevoie de un an și jumătate pentru a automatiza cam tot ce avea sens în proiectul nostru, dar aici ar trebui menționat că am avut de a face cu un proiect extrem de complex.

Îmbunătățiri viitoare

De-a lungul dezvoltării proiectului am observat câteva lucruri care ne-ar putea fi utile pe viitor. Unul dintre acestea se referă la testarea vizuală: facem o poză la un anumit moment în aplicație și o comparăm cu o altă poză de referință, despre care știm sigur că arată exact cum ar trebui să arate aplicația în acel punct.

LANSAREA NUMĂRULUI 82, CLUJ

Prezentări articole și
Panel: Dezvoltarea soluțiilor SAP

Marți, 16 Aprilie, ora 18:00
restaurant Hugo, The Office

Înregistrează-te

Facebook Meetup

Conferință

Sponsori

  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • Connatix
  • UIPatj
  • MetroSystems
  • Globant
  • MicroFocus
  • Colors in projects