Salut tuturor! Ne îndreptăm cu pași mici spre lumină și continuăm seria de articole despre produsul nostru. După partea anterioară, că în acest sistem se folosesc bifurcații speciale: articolul de informare, am primit numeroase feedback-uri (mai mult pozitive), sugestii și rapoarte de bug-uri. Astăzi vă vom arăta TestMace în acțiune, iar voi veți putea aprecia câteva dintre caracteristicile aplicației noastre. Pentru o imersiune mai completă, vă recomand să consultați documentația noastră la adresa http://docs-ru.testmace.com. Așadar, să începem!

Instalare

Să începem cu un evident. Aplicația este disponibilă și poate fi testată pe trei platforme — Linux, Windows, MacOS. Puteți descărca installer-ul pentru sistemul de operare dorit de pe site-ul nostru. Pentru utilizatorii de Linux există posibilitatea instalării a pachetului snap. Sperăm că în curând vom ajunge și la Microsoft Store și App Store (chiar trebuie? Ce credeți?).

Scenariul de testare

Am ales următorul scenariu de testare standard:

• ne vom loga: utilizator — admin, parola — password
• vom adăuga o nouă înregistrare
• vom verifica adăugarea corectă a înregistrării

Vom testa pe https://testmace-quick-start.herokuapp.com/. Este un simplu json-server, perfect pentru testarea de acest tip de aplicații. Am adăugat doar autorizarea prin token pe toate rutele json-server-ului și am creat metoda login pentru a obține acest token. Vom progresa pas cu pas, îmbunătățind treptat proiectul nostru.

Crearea proiectului și încercarea de a crea o entitate fără autorizare

Mai întâi, să creăm un nou proiect (File->New project). Dacă lansați aplicația pentru prima dată, noul proiect se va deschide automat. Haideți să încercăm să facem o cerere pentru crearea unei noi înregistrări (poate că crearea înregistrărilor este disponibilă fără autorizare). Selectați din meniul contextual al nodului Project opțiunile Add node -> RequestStep. Vom seta ca nume al nodului create-post. Rezultatul va fi un nou nod creat în arbore și se va deschide tabul acestuia. Să stabilim următoarele parametru pentru cerere:

• Tip cerere: POST
• url: https://testmace-quick-start.herokuapp.com/posts
• Corp cerere: json cu valoarea {"title": "New testmace quick start post"}
  Dacă ați făcut totul corect, interfața va arăta astfel:

Totuși, dacă vom încerca să executăm cererea, serverul va returna codul 401 și fără autorizare nu avem nici o șansă pe acest server. Ei bine, era de așteptat).

Adăugarea cererii de autorizare

Așa cum s-a menționat, avem un endpoint POST /login, care acceptă ca corp al cererii json de tip: {"username": "<username>", "password": "<password>"}, unde username și parola (de asemenea, din introducerea de mai sus) au valori admin și parola corespunzătoare. Ca răspuns, acest endpoint returnează un json de forma {"token": ""}. Vom folosi acest token pentru autentificare. Vom crea RequestStep un nod numit login, având ca părinte Proiect nodul. Folosind drag-and-drop, mutați acest nod în arbore mai sus decât nodul create-post. Să setăm următoarele parametre pentru cererea nou creată:

• Tip cerere: POST
• url: https://testmace-quick-start.herokuapp.com/login
• Corp cerere: json cu valoarea {"username": "admin", "password": "password"}

Executăm cererea și primim un cod 200 cu token-ul în răspuns. Așa arată:

Refactoring: eliminăm dublarea domeniului

Deocamdată, cererile nu sunt legate într-un singur scenariu. Dar acesta nu este singurul dezavantaj. Dacă ne uităm cu atenție, putem observa că cel puțin domeniul este duplicat în ambele cereri. Nu este bine. Este momentul să refactorizăm această parte a viitorului scenariu și ne vor ajuta variabilele.

În prima aproximare, variabilele îndeplinesc aceeași funcție ca în alte instrumente similare și limbaje de programare — eliminarea duplicării, îmbunătățirea lizibilității etc. Despre variabile puteți citi mai multe în documentația noastră. În acest caz, ne vor fi necesare variabilele utilizatorului.

Să definim la nivelul Project nodul o variabilă domain cu valoarea https://testmace-quick-start.herokuapp.com. Pentru aceasta, este necesar

• să deschideți fila acestui nod și să apăsați pe pictograma calculatorului din dreapta sus
• Apăsați pe + ADĂUGAȚI VARIABILA
• Introduceți numele și valoarea variabilei
  În cazul nostru, dialogul cu variabila adăugată va arăta astfel:

OK. Acum, datorită moștenirii, putem folosi această variabilă în descendantii oricărui nivel de imersie. În cazul nostru, acestea sunt nodurile login și create-post. Pentru a folosi variabila în câmpul text, este necesar să scrieți ${}. De exemplu, url pentru login se va transforma în ${domain}/login, în consecință pentru create-post nodul url va arăta ca ${domain}/posts.

Astfel, urmând principiul DRY, am îmbunătățit puțin scenariul.

Salvăm token-ul în variabilă

Deoarece am adus vorba despre variabile, să dezvoltăm puțin acest subiect. În prezent, în cazul unui login reușit, primim de la server un token de autorizare, pe care îl vom necesita în cererile ulterioare. Să salvăm acest token în variabilă. Deoarece valoarea variabilei va fi determinată în timpul executării scenariului, folosim pentru aceasta un mecanism special — variabile dinamice.

Pentru început, vom face o solicitare de autentificare. În tab-ul Parsed răspunsului, plasați cursorul pe token și în meniul contextual (care se deschide fie cu clic dreapta, fie prin apăsarea butonului …) selectați opțiunea Atribuie variabilei. Va apărea un dialog cu următoarele câmpuri:

• Path — ce parte din răspuns este preluată (în cazul nostru, aceasta este body.token)
• Current value — ce valoare se află pe calea Path (în cazul nostru, aceasta este valoarea token-ului)
• Numele variabilei — numele variabilei în care Current value va fi salvată. În cazul nostru, aceasta va fi token
• Node — în care dintre părinți va fi creată variabila Numele variabilei. Vom alege Project

Dialogul completat arată astfel:

Acum, la fiecare execuție a nodului login variabila dinamică token va fi actualizată cu o nouă valoare din răspuns. Și această variabilă va fi stocată în Proiect nod și, datorită moștenirii, va fi disponibilă descendenților.

Pentru a accesa variabilele dinamice, trebuie să folosiți variabila încorporată $dynamicVar. De exemplu, pentru a accesa token-ul salvat, trebuie să apelați ${$dynamicVar.token}.

Transmiteți token-ul de autorizare în solicitări

În pașii anteriori, am obținut token-ul de autorizare și tot ce trebuie să facem este să adăugăm antetul Authorization cu valoarea Bearer în toate solicitările care necesită autorizare, inclusiv în create-post. Există mai multe metode pentru aceasta:

1. Să copiăm manual token-ul și să adăugăm antetul de autorizare în solicitările de interes. Această metodă funcționează, dar aplicarea sa este limitată doar la solicitările de tip „am făcut și am aruncat”. Nu este potrivită pentru execuții multiple ale scenariilor.
2. Utilizați funcționalitatea de autorizare.
3. Utilizați anteturile implicite

Utilizarea celei de-a doua metode pare evidentă, dar în contextul acestui articol, această abordare… nu este interesantă. Adică, mecanismul de autorizare este cunoscut din alte instrumente (deși avem lucruri precum moștenirea autorizărilor) și probabil nu va ridica întrebări.

O altă poveste sunt anteturile implicite! Pe scurt, anteturile implicite sunt antete HTTP moștenite de la strămoșii lor, care sunt adăugate la cerere în mod implicit, dacă nu sunt dezactivate explicit. Cu această funcționalitate, putem, de exemplu, implementa o autorizare personalizată sau pur și simplu scăpa de duplicare în scripturi. Vom aplica această caracteristică pentru a transmite tokenul în antete.

Anterior, am salvat prudent tokenul într-o variabilă dinamică $dynamicVar.token la nivelul nodului Project. Rămâne să facem următoarele:

1. Definirea antetului implicit Authorization cu valoarea Bearer ${$dynamicVar.token} la nivelul nodului Project. Pentru aceasta, în interfața nodului Project, trebuie să deschidem dialogul cu antetele implicite (butonul Headers din colțul din dreapta sus) și să adăugăm antetul corespunzător. Dialogul cu valorile completate va arăta în felul următor:
   
2. Dezactivează acest antet din cererea de autentificare. Acest lucru este clar: în momentul autentificării nu avem încă tokenul și exact prin această cerere îl vom stabili. Așadar, în interfața cererii de autentificare, în tab-ul Headers din zona Inherited vom debifa căsuța cu antetul Authorization.

Asta e tot. Acum, antetul de autorizare va fi adăugat la toate cererile care sunt descendenți ai nodului Project, cu excepția nodului de autentificare. Așadar, la acest stadiu, avem deja un script pregătit și nu ne rămâne decât să-l lansăm. Putem lansa scriptul alegând opțiunea Run din meniul contextual al nodului Project.

Verificăm corectitudinea creării postării

La acest stadiu, scriptul nostru poate să se autentifice și, folosind tokenul de autorizare, să creeze o postare. Totuși, trebuie să ne asigurăm că noua postare are un nume corect. Așadar, practic rămâne de făcut următoarele:

• Trimiteți o cerere pentru a obține postarea după id,
• Verificați că numele primit de pe server corespunde numelui trimis la crearea postării

Să analizăm primul pas. Deoarece valoarea id-ului este determinată în timpul execuției scriptului, este necesar să creăm o variabilă dinamică (să o numim postId) din nodul create-post la nivelul nodului Project. Cum să facem acest lucru deja știm, este suficient să ne adresăm secțiunii Salvăm token-ul în variabilă. Rămâne doar să creăm o cerere pentru a obține postarea după acest id. Pentru aceasta, vom crea un RequestStep get-post cu următoarele parametrii:

• Tip cerere: GET
• URL: ${domain}/posts/${$dynamicVar.postId}

Pentru a implementa a doua etapă, trebuie să ne familiarizăm cu Afirmarea nodul. Nodul de Afirmare este un nod care permite scrierea de verificări pentru anumite cereri. Fiecare nod de Afirmare poate conține mai multe afirmații (verificări). Mai multe detalii despre toate tipurile de afirmații le puteți citi în documentation. Vom folosi Comparare afirmația cu operatorul egal. Există mai multe metode de creare a afirmațiilor:

1. Îndelungată. Manual, din meniul contextual al nodului RequestStep, creați un nod de Afirmare. În nodul de Afirmare creat, adăugați afirmația dorită și completați câmpurile.
2. Rapidă. Creați un nod de Afirmare împreună cu afirmația din răspunsul nodului RequestStep folosind meniul contextual

Vom folosi a doua metodă. Iată cum va arăta pentru cazul nostru.

Pentru cei care nu au înțeles, aici se întâmplă următoarele:

1. Faceți o cerere în nodul get-post
2. În tab-ul Parsed răspunsului, apelați meniul contextual și selectați Creează afirmație -> Comparare -> Egal

Felicitări, am creat primul test! Simplu, nu-i așa? Acum puteți rula întregul scenariu și vă puteți bucura de rezultat. Mai rămâne să refactorizăm puțin și să scoatem titlul într-o variabilă separată. Dar vă lăsăm acest lucru ca temă pentru acasă)

Concluzie

În acest ghid, am creat un scenariu complet și, de asemenea, am făcut o revizuire a unor funcționalități ale produsului nostru. Desigur, nu am folosit toate funcționalitățile, iar în articolele următoare vom face o revizuire detaliată a capabilităților TestMace. Rămâneți la curent cu actualizările!

P.S. Pentru cei care nu doresc să reproducă toți pașii, am realizat cu amabilitate repository proiectul din articol. Poate fi deschis folosind File -> Deschide proiectul și selectați folderul Proiect.

Sursa: habr.com