7 idei pentru un cod de testare automata eficient

Atunci cand ajungem intr-o pozitie de Automation QA prin angajare sau promovare dinspre sfera de testare manuala, una dintre cele mai importante activitati devine scrierea de cod pentru cazurile noastre de test ce trebuie automatizate. Aceasta este o activitate foarte faina, interesanta, dar care vine la pachet cu provocarile ei inerente.

Mai ales la inceput nu e deloc usor sa scriem un cod prea bun (cod „perfect” nu va exista niciodata), si suntem tentati sa facem anumite greseli sau lucruri care ne vor ingreuna proiectul in timp. De aceea, e recomandat sa urmam anumite sfaturi si idei care ne vor ghida la modul universal in a scrie un cod eficient pentru testare automata.

Acum ceva timp am vorbit de bune practici in testarea automata, ce tin de procesele generale de organizare a testarii. Acuma ne vom referi mai specific la scrierea efectiva de cod pentru automation.

7 idei pentru un cod de testare automata eficient

In cele ce urmeaza vom discuta un numar de sapte idei ce le consider necesare si importante daca vrem sa scriem un cod pentru niste teste automate care sa fie eficient, usor de inteles, reutilizabil si sa i se poata face mentenanta cat mai facil posibil. Aceste idei le-am invatat treptat in ultimul an de cand contribui pe partea de testare automata, practica efectiva ajutandu-ma sa le descopar si sa le pot sintetiza in aceasta forma pe blog.

1. Parametrizarea tuturor variabilelor

O prima idee ce mi-a fost explicata inca de la primele linii de cod scrise a fost aceea de a incerca sa nu adaug date de test efective in pasii si metodele din codul de automatizare. Aceasta situatie se cheama propriu-zis hardcodarea datelor in cod (”hardcoded test data”), si trebuie evitata din mai multe motive.

In primul rand, codul nostru devine mult mai greu de updatat in viitor daca vrem sa schimbam datele respective din toate locurile unde se afla ele plasate in cod. Presupunem ca avem un test automat care intr-un pas cauta un articol vestimentar pe un site de e-commerce, daca acolo am trecut efectiv ”T-Shirt” si ulterior vrem sa cautam ”Shoes”, atunci trebuie sa inlocuim manual din toti pasii respectivi, din toate testele acest element de test.

In loc de asta, solutia este sa parametrizam pasul sau metoda respectiva de cautare cu o variabila, sa zicem ipotetic shopArticle=”T-shirt”, pe care o punem in toti pasii din testele noastre de Search, iar daca vrem sa schimbam articolul, doar inlocuim valoarea din acea variabila si se updateaza peste tot ulterior. Eficienta este mult sporita astfel.

Un al doilea motiv pentru care e bine sa evitam pe cat posibil datele hardcodate in proiectul nostru este din ratiuni de securitate. De exemplu, la testele caracteristice functiei de login pe anumite aplicatii in mod evident folosim date de test precum usernames (sau adrese de email) si parole. Acestea e bine sa fie stocate in fisiere dedicate, eventual encriptate si parametrizate de asemenea pentru a putea…