În ultimii ani, pentru companiile de software devine din ce în ce mai evident că împlinirea cerințelor clientului este esențială. De aceea, procesul de testare a produselor este orientat tot mai mult în această direcție a clientului. Acceptance Test - Driven Development este una dintre practicile esențiale de testare pe care utilizatorii finali ajung să o valorifice pentru a-și valida produsul. Din acest motiv, aceasta are o mare importanță pentru client și totodată reprezintă și ultimul test major înainte de livrare. În acest articol voi prezenta cum se pot crea teste pentru Acceptance Testing Driven Development în .NET, utilizând SpecFlow și limbajul Gherkin. Specflow este un instrument open-source, care se integrează cu Visual Studio. De asemenea, articolul prezintă și cum se poate folosi Selenium Web Driver pentru a simula interacțiunea cu browser-ul.
Un proces de integrare continuă reușit este definit de teste automate care rulează rapid, au o acoperire bună și nu returnează rezultate eronate. Testele automate sunt de obicei împărțite în mai multe seturi, fiecare având obiectivul său: teste de unitate, teste de acceptare, teste de integrare, teste de sistem și teste de securitate.
Testele de acceptare reprezintă o etapă crucială în procesul de punere în funcțiune, întrucât permit echipelor care se ocupă de livrarea produsului să treacă dincolo de procesul de integrare continuă de bază. Odată ce testele automate de acceptare sunt implementate, se pot testa criteriile business de validare pentru aplicație, adică, se poate confirma că aplicația oferă funcționalitate de valoare utilizatorilor. Testele de acceptare sunt în mod tipic rulate pe fiecare versiune a software-ului care trece de testele unitare.
Un test de validare individual are scopul de a verifica dacă criteriile de acceptare a unei povești (story) sau cerințele business au fost îndeplinite. Criteriile de acceptare/ validare apar în multe variante: ele pot fi funcționale sau non-funcționale. Criteriile funcționale sunt legate de scenariile utilizatorului final (end-user), fiind strâns legate de procesele business pe care aplicația le face posibile. Criteriile non-funcționale se ocupă de operarea unui sistem, mai degrabă decât de comportamentul specific al funcțiilor. Performanța, capacitatea, disponibilitatea, siguranța, flexibilitatea la modificări, gestionarea erorilor și utilitatea sunt exemple bune de criterii de validare din punct de vedere nefuncțional. Ideea principală este aceea că o poveste sau o cerință specifică este considerată completă și funcțională numai atunci când se demonstrează că trece testul său de acceptare.
Un set de teste de acceptare, nu numai că asigură furnizarea valorii business așteptată de către utilizatorul final, dar ajută și la diminuarea potențialelor regresii ale defectelor sau ale modificărilor neașteptate ale funcțiilor aplicației. Testele automate de acceptare surprind probleme serioase pe care testele de unitate sau testele pe componente, oricât ar fi de cuprinzătoare, nu le-ar putea niciodată detecta. Din punctul de vedere al ciclului de dezvoltare, mai există un alt avantaj major al testării pentru acceptare: este unul dintre puținele procese care garantează faptul că toate grupurile sunt implicate în procesul de livrare - clienții, analiștii, managerii de proiect și echipa de dezvoltare (dezvoltatori, testeri și dev-ops).
Cheltuielile generale pentru a crea și a menține un set corespunzător de teste de acceptare sunt mai ales la aplicațiile complexe semnificativ mai mici decât costul efectuării manuale frecvente a testelor de regresie și validare, sau decât acela al alternativei de a scoate pe piață software de calitate slabă. O testare eficientă de acceptare ar trebui efectuată pentru fiecare lansare, drept o etapă formală odată ce dezvoltarea a fost finalizată și se apropie lansarea.
În lumea .NET, SpecFlow reprezintă unul dintre plugin-urile cele mai cunoscute pentru Acceptance Testing Driven Development.
SpecFlow are ca scop eliminarea problemelor de comunicare dintre experții care cunosc domeniul de business al aplicației și dezvoltatori, prin includerea specificațiilor de comportament în procesul de implementare efectivă, într-un limbaj ușor de citit și lipsit de ambiguitate. Este un instrument .NET open source inspirat de către framework-ul Cucumber, care permite scrierea specificațiilor în format Gherkin, fiind succint și ușor de interpretat de către o persoană. Gherkin este un limbaj Business Readable, specific domeniului, care vă permite să descrieți comportamentul software-ului fără a vă ocupa de modalitatea în care acel comportament este implementat sau de funcționalitatea cerută pentru un sistem dat.
Cele mai frecvent semnalate avantaje ale utilizării SpecFlow sunt :
încurajează colaborarea dintre membrii echipei - de profil tehnic sau business;
caracteristicile sistemului pot fi scrise și/sau înțelese de către persoane non-tehnice;
implementarea mai eficientă a modificărilor;
calitate mai ridicată a produsului;
Integrarea SpecFlow cu Visual Studio este simplă și constă în doi pași. Primul pas este să instalați Integrated Development Environmentul utilizând opțiunea Extensions and Updates din meniu, după cum puteți vedea pe imaginea de mai jos:
Ultimul pas este să configurați proiectul din Visual Studio, pentru a funcționa cu SpecFlow prin instalarea pachetului NuGet corespunzător.
SpecFlow suportă multiple framework-uri cunoscute de executare a testelor, precum Nunit și MsTest, dar de asemenea vine și cu un engine de executare de teste special creat, numit SpecFlow+Runner.
Ca și oricare alte teste din familia Cucumber, un test de validare SpecFlow necesită: un fișier de caracteristici (feature file), definirea pașilor și cod business.
Pentru a defini comportamentul sistemului, crearea unui fișier Feature este obligatoriu. Fișierul acesta conține privirea de ansamblu asupra funcționalității din user story și scenariile scrise în limbaj Gherkin. Este de preferat să avem echipe compuse din oameni cu diferite roluri în procesul de dezvoltare care să lucreze la crearea fișierului de caracteristici, deoarece aceasta duce la îmbunătățirea integrării și comunicării în echipă și reduce durata unui ciclu de dezvoltare pentru funcționalități noi. Un fișier de caracteristici de obicei conține o listă de scenarii, care începe cu cuvântul Scenariu (Scenario). Folosind etichetarea, se pot grupa laolaltă caracteristici și scenarii și se pot reutiliza părți din scenariile deja definite. Fiecare scenariu este definit printr-o listă de pași, care trebuie să înceapă cu unul dintre cuvintele cheie: Given (Dat), When (Când), Then (Apoi), But (Dar) sau And (Și).
Iată un exemplu:
Cuvântul cheie Given stabilește precondiții sau context pentru scenariu. Acțiunea, comportamentul pe care ne concentrăm este marcat prin When. Validarea scenariului este realizată utilizând afirmația Then; aceasta verifică de fapt dacă lucrurile corecte s-au petrecut în etapa When. And poate fi folosit în oricare dintre cele trei secțiuni și servește drept o frumoasă prescurtare pentru repetarea lui Given, When sau Then. Există anumite situații în care este necesar un pas negativ, și atunci poate fi utilizat cuvântul cheie But.
Traducerea liniilor în etape este efectuată prin click dreapta în fișierul de caracteristici și selectarea "Generate Step definition". Un ghid va crea scheletul fișierului pentru etape.
Executarea testelor de acceptare la nivelul UI necesită interacțiune cu browser-ul, iar aici Selenium Web Driver ne permite să abstractizăm comunicarea cu aplicația web. În interiorul etapelor auto-generate, noi putem executa diferite operații bazate pe funcționalitatea Selenium Web Driver, care facilitează interacțiunea cu Document Object Modelul unei pagini web.
Ca și oricare alt test automat, pentru a se putea ocupa de inițializarea testului și de curățarea sa, SpecFlow expune un set de evenimente care pot fi interceptate: BeforeScenario (Înainte de scenariu) și AfterScenario (După scenariu).
În general, acestea pot fi utilizate pentru a realiza logică adițională de automatizare pe evenimente specifice. Chiar dacă sunt globale, ele pot fi restricționate pentru a rula numai pentru funcționalități sau scenarii specifice. Hook-urile BeforeScenario și AfterScenario conțin logică de automatizare care trebuie să ruleze înainte/după executarea fiecărui scenariu ca și în cazul inițializării browser-ului la începutul fiecărui scenariu și dealocarea obiectelor browser-ului după fiecare executare de test.
Atunci când creăm un test de validare cu SpecFlow, ar trebui să luăm în considerare următoarele drept bune practici:
Fișierele de caracteristici ar trebui să fie de fapt caracteristici și nu porțiuni întregi din aplicație, ar trebui să folosească titluri sau etichete descriptive și să conțină scenarii care sunt independente și deterministe.
Etapele ar trebui să fie bucăți mici, simple și concise de cod. Ar fi de dorit ca ele să fie reutilizabile, să aibă o sigură responsabilitate și o separare bună a preocupărilor (concerns)
Scrieți scenarii și pentru cazurile non-happy-flow.
Testele automate de acceptare reprezintă un pas important în procesul de Continuous Integration, sunt nu numai barieră a calității în procesul de livrare, dar contribuie semnificativ la crearea documentației pentru procesele de business, care ne ajută să evităm problemele comune de mentenanță pe termen lung.
Implementarea testelor de acceptare conduce la formare de echipe interfuncționale în care testerii, analiștii și dezvoltatorii lucrează împreună pentru a dezvolta în mod corect funcționalitățile sistemului. Dacă comunicarea dintre părțile interesate și dezvoltatori este clară, echipele de software funcționează cel mai bine, iar evitarea neînțelegerilor prin definirea testelor de acceptare va crește nivelul de colaborare al echipei.
Implementarea testelor de acceptare folosind instrumentul SpecFlow ne permite să utilizăm exemple și concepte din lumea reală pentru a descrie comportamentul sistemului pe înțelesul acționarilor.
"Specification by Example: How Successful Teams Deliver the Right Software" 1st Edition 2011 by Gojko Adzic
"The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers) 1st Edition" 2012 by Matt Wynne and Aslak Hellesøy
de Mihnea Lazăr
de Andrei Cacio
