Meniu

Introducere în testarea contractelor cu exemple

introduction contract testing with examples

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

tipuri de defecte în testarea software-ului

Acest tutorial privind testarea contractelor de pact explică ce este testarea contractelor bazate pe consumatori, cum funcționează și de ce ar trebui să o utilizați în strategia de testare:

Ce este testarea contractului?

Testarea contractelor bazate pe consumatori este o formă de testare API care permite cu adevărat trecerea la stânga. Instrumentul de contract pe care îl folosim este Pact.io , și vom afla despre asta mai târziu în această serie de tutoriale.

Testarea contractului este o metodă de verificare a integrării între două aplicații în mod independent, pentru a testa ceea ce a fost trecut și a vedea dacă ceea ce este returnat se potrivește cu „contractul”.

Testele contractuale se încadrează frumos într-o arhitectură de microservicii, funcționând într-un cadru agil. Prin urmare, exemplele se vor baza pe experiența pe care am acumulat-o în timp ce lucram în acest mediu.

Testarea contractului

Ce veți învăța:

Lista tutorialelor din această serie de teste contractuale

Tutorial nr. 1: Introducere în testarea contractelor cu exemple (Acest tutorial)
Tutorial nr. 2: Cum se scrie un test al pactului consumatorului în JavaScript
Tutorial # 3: Cum să publicați un contract de pact pentru un broker de pact
Tutorial # 4: Verificați contractul Pact și implementarea continuă cu Pact CLI

Testarea contractelor bazate pe consumatori

Punctul de plecare este documentația dvs. API care formează contractul pentru testele dvs., în acest moment, de obicei, echipele de dezvoltare iau documentul API și se dezvoltă în funcție de documentul wiki (sau de orice format se află în organizația dvs., cum ar fi Word Document).

De exemplu, o aplicație web în care front-end-ul este dezvoltat de Team Krypton și API-ul este dezvoltat de Team Thoron. Proiectul începe cu o întâlnire inițială în care cerințele sunt prezentate și convenite între echipe.

Fiecare echipă preia cerințele și începe să creeze restanțele prin rafinarea poveștilor. Dezvoltarea începe în ambele echipe în urma poveștilor utilizatorilor, testarea integrării este lăsată pentru sprinturi ulterioare. Pe măsură ce Team Krypton găsește cerințe suplimentare, referitoare la scenariile de eroare, documentația API este actualizată în consecință.

Cazurile de testare sunt adăugate de Team Thoron în legătură cu scenariile actualizate pe baza documentației.

Deja putem vedea câteva defecte cu acest proces și am adăugat încă câteva pentru noroc:

  1. Este posibil ca modificările documentelor API să nu fie comunicate în mod eficient.
  2. Echipa front-end elimină serviciul back-end și invers.
  3. Echipa back-end creează cazuri de testare a integrării pe baza documentației.
  4. Mediul de integrare este prima dată când se testează integrarea completă.
  5. Versiune API diferită pentru mediul de integrare vs producție.

Testarea contractelor bazate pe consumatori are două părți, adică consumatorul și furnizorul. Aici se întoarce gândirea tradițională despre testarea în microservicii.

Consumator este curatorul scenariilor, inclusiv cererea și răspunsul așteptat. Acest lucru vă permite să urmăriți Legea patului ceea ce vă dictează ar trebui să fiți flexibili în ceea ce API-ul dvs. poate accepta, dar conservator în ceea ce este trimis. Referindu-ne la defectele nr. 1, 3 și 4, modificările documentației sunt conduse de consumator.

De exemplu, în situația în care echipa Thoron schimbă un câmp șir pentru a nu accepta valori nule, testele consumatorului nu ar reflecta schimbarea și, prin urmare, ar eșua. Sau cel puțin până când modificările au fost făcute la Team Krypton.

Definiți așteptările consumatorilor

(imagine sursă )

Furnizor verifică scenariile oferite de consumator în raport cu mediul lor „dev”. Acest lucru permite aplicarea microserviciilor Schimbare paralelă care afirmă că ar trebui să extindeți funcționalitatea API, urmată de migrarea la o nouă versiune. Referindu-ne înapoi la defectul nr. 2, butoanele create de obicei de echipele back-end pentru propriile cerințe de testare pot fi acum bazate pe scenariile consumatorilor folosind Pact Stub Server .

Verificați așteptările furnizorului

Elementul obligatoriu al celor două părți este „contractul” care trebuie împărțit între echipe. Pactul oferă o platformă care să permită partajarea contractelor numite Pact Broker (disponibil ca serviciu gestionat cu Pactflow.io ).

Agent stochează rezultatele scenariilor de consum. Contractul este apoi stocat în cadrul brokerului alături de versiunea API. Acest lucru permite testarea împotriva mai multor versiuni ale API-ului, astfel compatibilitatea poate fi confirmată înainte de lansare, așa cum este evidențiat în defectul nr.5.

diagramă_rețea_pact
Pact Broker - Reprezentare vizuală

Un avantaj suplimentar pentru Pact Broker pe platformele vechi este vizibilitatea consumatorilor. Nu toți consumatorii au fost cunoscuți de autorii API-ului, mai ales că nu este modul în care este consumat.

Referindu-se în mod specific la o apariție în care două versiuni API erau acceptate, a existat o problemă de date în versiunea 1 (V1) prin care API a cauzat date murdare în baza de date.

Schimbarea a fost implementată în V1 a API-ului și a fost introdusă în producție, totuși, consumatorul s-a bazat pe formatul care a cauzat problema datelor, rupând astfel integrarea lor cu API-ul.

Cum functioneazã

Flux de autentificare

Exemplul de mai sus arată fluxul de autentificare, serviciul web solicită utilizatorilor să se autentifice pentru a accesa date sensibile. Serviciul web trimite o cerere către API pentru a genera un simbol folosind un nume de utilizator și o parolă. API returnează un jeton purtător care este adăugat la cererea de date ca antet de autentificare.

Testul consumatorului construiește o cerere POST pentru un simbol prin trecerea corpului cu numele de utilizator și parola.

Cerere POST

Un server fals este activat în timpul testului, care validează solicitarea pe care o construiți, împreună cu răspunsul așteptat, care în acest exemplu include valoarea pentru jeton.

server simulat

Rezultatul testului consumatorului generează un dosar de contract de pact. Aceasta va fi stocată în brokerul de pact ca versiunea 1.

Furnizorul extrage apoi versiunea 1 de la brokerul de pact și redă această cerere împotriva mediului lor local, verificând cererea și răspunsul care corespund cerințelor consumatorilor.

broker de pact

Roluri si responsabilitati

Roluri si responsabilitati

Asigurarea calității (QA) / Tester: Crearea de contracte folosind Pact.io și colaborarea cu BA pentru a genera scenarii de testare.

Dezvoltator: Îmbinarea cu QA-urile pentru crearea testelor și pentru a ajuta la înfășurarea API-ului pentru implementare în integrare continuă (CI).

Analist de afaceri (BA): Generarea scenariilor și colaborarea cu arhitectul pentru a verifica părțile afectate.

Solution Architect (Este posibil să nu existe în organizația dvs.): Acționarea modificărilor API și coordonarea cu BA la implementare, comunicând, de asemenea, modificările către consumatori (folosind Pact Broker pentru a înțelege pe cine ar putea să îl intereseze).

Managementul lansării: (Da, știu că este de modă veche, dar încă există în lumea mea): plin de încredere că modificările vor fi lansate cu succes datorită acoperirii testării contractului.

Intreaga echipa: Verificați rezultatele pentru a determina dacă versiunile pot fi împinse la producție cu instrumentul Pact CLI, Pot să implementez .

Testarea contractelor Vs Testarea integrării

Testarea integrării trebuie să existe pentru a valida dacă sistemul funcționează înainte de promovarea în mediul de producție, dar scenariile pot fi reduse semnificativ.

Impactul acestui lucru ar putea fi:

  • Feedback mai rapid înainte de lansare în mediul de integrare.
  • Mai puțină dependență de stabilitatea mediului de integrare.
  • Mai puține medii care acceptă mai multe versiuni API.
  • Instanțe de mediu instabile reduse din cauza problemelor de integrare.
IntegrareContracta
Evidențiați clar eșeculMulte straturiFoarte usor
Configurare APIdaNu face
Verificări de implementaredaNu face
Versiune APIdada
Depanare localăNu faceda
Probleme de mediudaNu face
Timp de feedbackÎncetRapid

În primul rând, testarea contractelor nu înlocuiește testarea integrării. Dar, probabil, poate înlocui unele dintre scenariile dvs. existente de testare a integrării, poate trece la stânga și oferă feedback mai rapid ciclului de viață al dezvoltării software-ului.

În testarea integrării, veți verifica contextul în care trăiește API, cum ar fi arhitectura mediului, procesul de implementare etc.

Prin urmare, doriți să rulați scenariile de testare de bază care ar confirma configurația, de exemplu, punctul final al verificării stării de sănătate pentru versiunea API. De asemenea, dovedind dacă implementarea a avut succes prin returnarea unui răspuns 200.

În testarea contractului, testați specificul API-ului, care include cazurile marginale legate de structura API, conținut (de exemplu, valorile câmpului, cheile există) și răspunsurile la erori. De exemplu, API gestionează valori nule sau sunt eliminate din răspunsul API (un alt exemplu real).

Unele beneficii (dacă nu sunteți deja vândut)

Mai jos sunt enumerate câteva dintre beneficiile pe care le puteți folosi în timp ce vindeți testarea contractelor către o afacere mai largă:

  • Implementarea mai rapidă a software-ului
  • O singură sursă de adevăr
  • Vizibilitatea tuturor consumatorilor
  • Ușurința de testare față de diferite versiuni API.

întrebări frecvente

Câteva întrebări frecvente în timp ce încercăm să convingem oamenii să adopte testarea contractului includ:

Q # 1) Avem 100% acoperire de testare deja, deci nu avem nevoie de ea.

Răspuns: Ei bine, acest lucru este imposibil, dar testarea contractelor are multe alte avantaje decât simpla acoperire a testelor.

Q # 2) Este responsabilitatea Arhitectului soluției să comunice modificările API.

Răspuns: Calitatea este responsabilitatea întregii echipe.

Î. 3) De ce creăm scenariile de testare pentru echipa API?

Răspuns: Echipa API nu știe cum funcționează serviciul web, deci de ce ar trebui să fie responsabilă.

Q # 4) Testele noastre end-to-end acoperă întregul flux de la început până la sfârșit, inclusiv alte puncte de integrare.

Răspuns: Exact de ce împărțim testele pentru a testa un lucru și nu este responsabilitatea dvs. să testați fluxul de la un capăt la altul al unui sistem pe care nu știți cum funcționează.

Q # 5) În depozitul în care echipă trăiesc testele?

Răspuns: Ambii. Consumatorul în depozitul lor și Furnizorul în al lor. Apoi, în punctul central, contractul trăiește în afara oricăreia dintre ele.

Argumente

Acestea sunt argumentele pe care ne este greu să le argumentăm atunci când vine vorba de trecerea la contract pentru a testa:

  • Documentație Swagger deja în vigoare, care poate fi utilizată pentru a genera teste de integrare.
  • Echipele dețin atât servicii front-end, cât și back-end, cu un mecanism eficient pentru modificările API.

Integrare continuă

Cum se încadrează acest lucru în suita de testare a integrării continue? Locul dorit pentru a trăi testarea contractului este cu testele unitare.

Testele pentru consumatori creează un server simulat care nu necesită dependențe externe în afara testului.

Testele furnizorilor necesită o instanță API, prin urmare API-ul local poate fi înfășurat folosind un server de testare în memorie . Cu toate acestea, dacă nu este ușor să vă înfășurați API-ul local, o soluție pe care am folosit-o anterior este aceea în care am creat un mediu și implementăm codul în acest mediu ca parte a verificărilor automate ale cererii de extragere.

întrebări și răspunsuri de interviu pentru MySQL pentru o experiență de 3 ani

Integrare continuă

Video de integrare continuă

Integrare continuă 3

(imagine sursă )

Concluzie

În acest tutorial, am aflat ce înseamnă testarea contractelor și cum arată într-o infrastructură de microservicii și am văzut cum arată într-un exemplu din lumea reală.

Au fost învățate lecții despre modul în care testarea contractelor vă poate ajuta să vă deplasați testarea integrării spre stânga. În plus, am văzut cum poate reduce costurile pentru organizația dvs. prin reducerea timpilor de feedback legați de problemele de integrare.

Testarea contractelor nu este doar un instrument pentru testarea tehnică, ci impune colaborarea echipelor de dezvoltare prin comunicarea modificărilor și încurajarea testării ca o singură unitate. În general, aceasta ar trebui să fie o condiție prealabilă pentru oricine dorește să treacă la implementarea continuă.

NEXT Tutorial

Lectură recomandată

^