Cucumber si Gherkin – baza testelor automate in limbaj natural

Testarea intr-un mod automatizat reprezinta o componenta esentiala in procesul de testare modern, aplicat preponderent in zilele noastre. Testele automate prezinta un avantaj foarte mare, si anume ca reduc semnificativ timpii de testare pentru anumite feature-uri din produsele software ce ar fi redundat de verificat manual frecvent (ex: textul butonului de login).

Testele automate pot fi scrise si organizate in multe moduri, in functie de arhitectura si specificatiile proiectului respectiv. Ca design pattern de automation, am vorbit in trecut despre Page Object Model. In continuare vom vedea ca pasii din executia testelor pot fi scrisi intr-o formula destul de simpla, in limbaj natural, cu ajutorul a doua instrumente dedicate, si anume Gherkin si Cucumber.

Ce este BDD?

Pentru a intelege foarte clar ceea ce vom discuta in continuare, cum si de ce testele automate se scriu in limbaj natural si nu doar in maniera clasica, in linii de cod, vom aborda subiectul BDD.

Acronimul BDD vine de la Behaviour-Driven Development, si constituie o abordare de lucru uzitata des in lumea testarii software si a developmentului.  Aceasta abordare BDD presupune dezvoltarea produselor software si a testelor automate care le verifica intr-o maniera corelata cu cerintele de business ale produselor respective.

Mai concret, paradigma BDD presupune o colaborare continua intre analistii de business, intre developeri si testeri (QA), prin care focusul este indreptat spre comportamentul final al aplicatiei, iar functiile de cod si testele care verifica implementarea cerintelor de business sunt redactate intr-un limbaj natural, comun tuturor celor 3 parti implicate (tehnic si non-tehnic).

Astfel, testele automatizate care sunt cunoscute si intelese din punct de vedere al functiilor tehnice de catre QA pot fi citite cu mare usurinta de aproape orice persoana care nu a fost implicata in realizarea lor si intelese din perspectiva acelor feature-uri implementate.

Pentru a fi capabili sa scriem pasii testelor automate in limbaj natural, simplu si usor de inteles, trebuie sa folosim 2 instrumente extrem de populare ce au fost dezvoltate tocmai cu acest scop, asa cum aminteam anterior, si anume Gherkin si Cucumber.

La ce ajuta Gherkin?

Primul tool despre care voi discuta (si voi detalia la momentul potrivit de ce) este Gherkin. Acesta (tradus drept „muratura”) este propriu-zis un plug-in, un software aditional pe care il putem instala, ca oricare alta extensie, in editorul nostru de cod unde dezvoltam teste automatizate: Visual Studio Code, Intellij, PyCharm etc.

Pentru a instala si folosi Gherkin si Cucumber, tot ce trebuie sa facem este sa deschidem IDE-ul folosit de noi, sa selectam sectiunea de extensii sau plug-ins, sa cautam dupa Cucumber si sa dam click pe butonul Install. Dupa cateva secunde si un refresh, avem instalat Cucumber care vine la pachet cu Gherkin.

Acest lucru se datoreaza faptului ca dezvoltarea acestor instrumente software a pornit de la Cucumber si ulterior a fost implementat si Gherkin, iar cele 2 extensii merg mana in mana.

Gherkin ne ajuta pentru ca este acea componenta care ne permite scrierea efectiva intr-un limbaj natural, uzual, a pasilor care compun testele automate. Integrarea lui Gherkin este extrem de mare, astfel incat se pot folosi in jur de 70 limbi pentru acesta. Cea mai folosita optiune este in mod firesc engleza, dar ca idee se pot scrie teste si in franceza, germana, araba, romana etc.

De aici rezulta si marele sau avantaj, ca aproape orice persoana, chiar si dintr-o zona non-tehnica, poate intelege un test automat scris cu Gherkin si ce functionalitate verifica acesta.

Gherkin se bazeaza pe niste cuvinte cheie, care se folosesc cu un scop precis in constructia testelor automatizate. Acestea sunt:

• Feature
• Rule
• Scenario
• Given, When, Then, And, But – acestia se folosesc pentru detalierea pasilor de initiere, a pasilor de executie din timpul testului si pentru declararea asertiilor care verifica corectitudinea executarii pasilor.
• Background
• Scenario Outline
• Examples (sau Scenarios)

Pe langa acestea, mai sunt si cateva sene speciale care intra tot in aceasta categorie: “”” (date tip String), | (tabel de date), @ (tag-uri), si # (comentarii).

Testele scrise in limbaj natural cu Gherkin vor fi astfel organizate intr-o pagina speciala, dedicata functionalitatii pe care o verifica, acel fisier fiind generic denumit Feature File. De exemplu, daca avem teste ce verifica functia de Login pe un website, putem denumi fisierul nostru Login.feature, si acolo trecem pasii creati cu Gherkin.

Cucumber si definirea pasilor in framework-ul de testare

Al doilea tool care ajuta in procesul de scriere a testelor noastre intr-un mod cat mai inteligibil este Cucumber. Acest plug-in dezvoltat in jurul anului 2008 ne ajuta in continuarea procesului de scriere a testelor in limbaj comun si inteles de toata lumea.

Mai precis, Cucumber ajuta la definirea pasilor pe care i-am scris in Feature File cu ajutorul lui Gherkin. De aici deriva si motivul pentru care am inceput discutia de la Gherkin. Prima data scriem in fila dedicata acelui feature un pas, de genul When user is clicking on Search button.

Daca ne rezumam doar la scrierea acelui pas asa si atat, atunci nu se va intampla nimic in spate, nu se va executa nicio actiune. De ce? Pentru ca nu am definit acel pas sa face ceva in spate. Si de aici incepe treaba lui Cucumber.

Dupa ce scriem un pas in limba comuna, selectam din IDE functia de Create Step Definition si vom fi redirectionati la o alta fila caracteristica, si anume Steps Definition File (daca nu exista deja una, se va crea). Aici incepem sa scriem primele linii de cod, care presupun folosirea anumitor parametri si variabile care sa ne ajute sa executam propriu-zis pasul ce tocmai l-am generat.

Aceste variabile din aceasta fila sunt specifice proiectului, si pentru a le folosi la randul lor vor trebui definite intr-un alt treilea fisier denumit Page file, unde este codul ce executa pasii in sens de coding (variabile, selectori, locatori, functii, if-uri si for-uri etc.).

Astfel, Cucumber asigura legatura intre cuvintele normale ale limbii, cele care ne fac sa intelegm pasii scrisi cu Gherkin si codul din spatele acestora care executa respectiva actiune sau care verifica o anumita asertie.

Exemple de folosire a lui Cucumber si Gherkin

Pentru a fi si mai clar modul in care functioneaza si se folosesc extensiile de Cucumber si Gherkin intr-un proiect de testare automata, vom vedea in continuare cateva exemple. Trebuie mentionat ca aceste tool-uri se pot integra si folosi extrem de bine cu framework-urile de automatizare Cypress si Selenium, astfel ca orice am alege la inceput pentru a deprinde testarea automata ca etapa in cariera de QA, nu vom avea probleme in a invata si partea de Cucumber/ Gherkin.

Pentru inceput, sa vedem un exemplu foarte simplu de test automat ai carui pasi sunt scrisi cu Gherkin.

In acest caz, putem observa structura unui test scris cu Gherkin pe baza cuvintelor cheie. Feature descrie care e functionalitatea verificata (poate fi ceva generic precum Login), Scenario descrie titlul acelui test si ce anume se verifica mai exact. Ulterior urmeaza suita de termeni Given / When / Then, care compun testul automat in sens practic. Prin Given se stabileste situatia initiala, ce (pre)conditii avem ca sa porneasca acel test.

When descrie un pas concret pe care utilizatorul il executa pentru a realiza un anumit pas in cadrul aplicatiei (da click pe ceva, tasteaza anumiti termeni etc.). Iar Then este folosit pentru a introduce asertii in test, prin care sa ne asiguram ca se verifica ceea ce trebuie conform logicii de business prestabilite.

Pe langa Given / When / Then, Gherkin mai poate folosi si And / But atunci cand avem mai multi pasi, respectiv asertii consecutive si nu vrem sa repetam keyword-ul initial, insa nu e obligatoriu.

In acest exemplu de test in Gherkin apare si un tag, @test. Acestea se folosesc pentru a putea selecta uneori ce teste vrem sa rulam, nu toate o data. Daca sa zicem aveam tag-ul @search-article, atunci ipotetic s-ar fi rulat doar testele legate de functia de search a articolelor de pe site.

Sa vedem si un exemplu de step definition unde intervine Cucumber.

Aici am selectat pasul formulat mai inainte cu ajutorul lui Gherkin, When User reads the new blog article, si l-am definit cu ajutorul lui Cucumber. Pasul apare in Step Definition file, si este parametrizat, sustinand 2 parametri: parametrul ”user” (care user concret face actiunea) si ”article” (care articol concret este accesat).

In cadrul acestui pas este definita o clasa denumita theArticleIsSelected, deci un nume relevant si cat mai intuitiv, iar in cadrul ei am conceput ipotetic pasul prin care din clasa mai mare pages se executa metodele getArticle si byUser, fiecare folosind parametrul corespunzator pe care i-am mentionat anterior.

Aceste metode insa daca nu sunt si ele la randul lor create undeva in proiect, nu vor executa nimic. Acesta este doar un exemplu foarte succint de pas definit cu ajutorul Cucumber, lucrurile putand deveni mult mai complexe, in cadrul unui proiect de testare automata. Insa acesta este modul general de organizare al testelor scrise in limbaj uzual cu Gherkin, definite apoi cu Cucumber.

Importanta, avantaje si dezavantaje ale lui Gherkin si Cucumber

Folosirea plug-in-urilor Cucumber si Gherkin este extrem de raspandita in proiectele de automatizare din industria IT, ajutand extrem de mult la inchegarea unor teste cat mai comprehensibile. Importanta lor este una evidenta, fiind mult mai usor de a intelege anumite teste si anumiti pasi, uniformizand modurile de lucru ale diferitelor echipe.

Cucumber si Gherkin, ca oricare alta tehnologie, prezinta atat avantaje, cat si dezavantaje. Printre avantaje, asa cum am putut observa deja, se regaseste faptul ca simplifica extrem de mult scrierea si intelegerea testelor automatizate, chiar daca peste ele se uita un QA, un programator sau cineva din sfera de business/ non-tehnica.

De asemenea, folosirea acestor extensii conduce pe termen mediu si lung la o coerenta si uniformitate mai mare a pasilor folositi in teste. Practic, un pas definit si parametrizat corect poate fi folosit in oricate teste, nu trebuie rescris si redefinit de la 0 mereu.

Acest lucru conduce la un alt avantaj, si anume ca simplifica procesul de mentenanta a testelor automate, pentru ca daca se schimba ceva la un element sau o metoda, aceasta se va corecta ulterior in toate testele unde e folosita, nu trebuie luate unul cate unul, deci o rapiditate mult mai mare si o mentenanta mai abordabila.

Exista si unele dezavantaje in folosirea lui Cucumber si Gherkin. Pentru incepatorii in testare este mult mai greu sa inteleaga acest sistem cu multe fisiere si continutul acestora, existand o panta abrupta in invatarea lor, desi pe termen lung folosirea devine mai clara si mult mai usoara decat daca nu s-ar folosi.

Pe langa asta, integrarea lui Cucumber si Gherkin poate fi uneori problematica cu anumite medii de lucru (environments), in special daca e vorba de un proiect deja existent, care nu a fost gandit de la inceput cu aceste extensii.

Concluzii

In incheiere, Cucumber si Gherkin reprezinta doua extensii extrem de utile care ajuta la scrierea testelor automate intr-un limbaj natural, cat mai abordabil si usor de inteles inclusiv de cei care nu au cunostinte de automatizare, in baza abordarii BDD.

Aceste instrumente ajuta extrem de mult la intelegerea testelor, la o mai buna testare a anumitor feature-uri din aplicatie si la o dezvoltare mai durabila a testelor, asigurand o mentenanta mai usor de abordat in mod practic.

Folosirea Cucumber si Gherkin este extrem de raspandita, fapt ce le transforma in niste tool-uri foarte bune de stiut pentru experienta noastra de QA.

Surse consultate si aditionale

Documentatia oficiala a lui Gherkin, cu detalii despre cuvintele cheie si organizarea pasilor in testele automate

Documentatia oficiala a lui Cucumber, unde sunt detalii despre Steps Definitions, Cucumber expressions si diverse resurse utile.

Detalii despre Behaviour-Driven Development (BDD) gasesti aici si aici.

Mai multe informatii si exemple despre Feature si Steps files (Cucumber) si sintaxa lui Gherkin

Despre Page Object Model