This is an old revision of the document!
Laborator 08 - Integration Testing
Testarea de integrare
Testarea de integrare este un tip de testare în care două sau mai multe componente diferite ale unei aplicații software sunt testate împreună pentru a valida corectitudinea interacțiunii dintre acestea. Testarea de integrare este realizată de obicei după testarea unitară și ajută la identificarea timpurie a defectelor aplicației pe parcursul ciclului de dezvoltare.
Testarea de Integrare în Piramida de Testare
Piramida de Testare este un framework popular care ilustrează proporția diferitelor tipuri de teste într-o strategie de testare software. Ideea este să se concentreze resursele pe automatizarea testelor la niveluri inferioare (teste unitare și de integrare) și să se minimizeze testele E2E (end-to-end), care sunt mai costisitoare.
Cele 3 niveluri ale piramidei sunt:
Testarea Unitară: Baza piramidei. Se concentrează pe componente individuale. Sunt rapide și de obicei automatizate.
Testarea de Integrare: Nivelul intermediar. Verifică interacțiunile dintre componentele integrate.
Testarea E2E: Vârful piramidei. Verifică întregul sistem din perspectiva utilizatorului. Sunt mai puține la număr, mai lente și mai fragile.
Abordări în Testarea de Integrare
Există două abordări principale:
Abordarea Big Bang
Abordarea Incrementală
1. Testarea de Integrare Big Bang
În această abordare, toate modulele sunt integrate și testate simultan, ca un întreg.
Avantaje:
Potrivită pentru sisteme simple, cu puține dependențe între componente
Nu necesită planificare amănunțită
Ușor de configurat, toate modulele sunt integrate dintr-odată
Efort redus de coordonare și management
Dezavantaje:
Costisitoare și consumatoare de timp pentru sisteme mari
Detectarea defecțiunilor este întârziată
Greu de identificat erorile în module specifice
Dificil de depanat din cauza complexității
Recomandări:
Definirea clară a interacțiunilor dintre module
Logare detaliată pentru localizarea precisă a erorilor
Util pentru aplicații simple
2. Testarea de Integrare Incrementală
Modulele cu logică apropiată sunt grupate și testate treptat, nu toate simultan. Procesul continuă până când toate modulele sunt integrate și testate.
Avantaje:
Detectarea timpurie a defecțiunilor
Localizarea mai ușoară a problemelor
Strategie de testare mai flexibilă
Dezavantaje:
La începutul proiectului, unele funcționalități pot lipsi, necesitând „stubs” și „drivers”
Necesită definirea completă a sistemului pentru a putea fi împărțit în module mici
Testare de Integrare Top-down vs. Bottom-up
Testarea incrementală poate fi împărțită în:
Bottom-up: Se testează mai întâi componentele low-level (fundamentale), apoi cele high-level
Top-down: Se începe cu componentele high-level (complexe), apoi cele low-level
Hibrid: Se combină cele două abordări
Componente low-level: funcții simple, structuri de date
Componente de high-level: management utilizatori, procesare comenzi, mecanisme de securitate
Exemplu comparativ (site eCommerce):
1. Testarea Bottom-up
Se începe cu modulele low-level și se urcă treptat. De exemplu: de la „tricouri” → „haine bărbați” → „îmbrăcăminte”.
Când să o folosești:
Complexitatea este în componentele low-level
Se dezvoltă incremental
Localizarea defecțiunilor este esențială
Componentele high-level nu sunt încă dezvoltate
2. Testarea Top-down
Se pornește de la modulele high-level către cele low-level. Oferă o imagine de ansamblu devreme în proiect.
Când să o folosești:
Funcționalitățile critice sunt în componentele high-level
Se dorește simularea interacțiunii utilizatorului
Modulele low-level sunt stabile
Se dorește validarea rapidă a funcționalităților vizibile
3. Testarea Hibridă (Sandwich)
Se combină top-down și bottom-up.
Avantaje:
Dezavantaje:
Planificare și coordonare complexă
Necesită comunicare eficientă în echipă
Dificultate în schimbarea între metodele de integrare
Exerciții
Pentru a clona repo-ul și a accesa resursele aferente laboratorului:
student@tsc:~$ git clone git@github.com:cs-pub-ro/systems-testing.git
student@tsc:~$ cd systems-testing/laboratories
student@tsc:~/laboratories$ cd integration-testing
Dacă aveți local repo-ul, asigurați-vă că aveți ultima versiune.
student@tsc:~$ cd systems-testing
student@tsc:~$ git pull
Setup
pip install pytest
pip install requests
În partea practică vom realiza teste de integrare pentru o aplicație web de tip REST API care permite gestionarea task-urilor personale, fiind disponibilă aici: https://todo.pixegami.io. Un task este caracterizat de un user id, task id, descriere (content) și status de finalizare (is_done).
În documentația aplicației (https://todo.pixegami.io/docs) sunt descrise operațiile expuse, și anume:
crearea unui task
obținerea unui task
listarea task-urilor
modificarea unui task
ștergerea unui task
După ce a fost realizată testarea unitara a modulelor aplicației (endpoints, baze de date, s.a.), trebuie să fie validată interacțiunea dintre acestea. Astfel, se dorește să se testeze ca operațiile pe task-uri descrise mai sus se execută cu succes.
Hint: validarea creării unui task presupune 2 request-uri, unul de PUT și altul de GET, testând interacțiunea dintre clientul web, endpoint-ul web și baza de date în care se stochează task-urile.
Verificare: validați că request-urile întorc codurile de status HTTP corecte (200 în cazul lui PUT și GET) și că body-ul răspunsului primit este cel așteptat (în cazul lui GET, json-ul din body-ul primit ca răspuns trebuie să conțină task-ul introdus prin acțiunea PUT: content, user_id, is_done).
Atenție: task_id-ul este generat random server-side, astfel că task-id-ul trimis prin operația de PUT in create_task este irelevant, iar răspunsul request-ului create_task va conține task-id-ul generat.
Hint: Creați 3 task-uri sub același user_id, apoi validați că operația de listare întoarce 3 task-uri.
Sugestie: Încercați să generați user_id-uri unice, altfel există șansa ca operația de listare să vă întoarcă task-uri.
Hint: Trebuie să validați că după operația de ștergere, un task nu poate fi obținut prin GET.
5. Implementați câte un test care verifică comportamentul
API-ului atunci când se încearcă accesarea (
GET), modificarea (
UPDATE) sau ștergerea (
DELETE) unui task inexistent.
Hint: Pentru fiecare operație folosiți un task id generat unic pentru a simula un task inexistent.
Pentru UPDATE API-ul răspunde cu 200 și creează task-ul dacă nu există deja, puteți verifica ulterior cu GET.
6. Implementați un test care verifică comportamentul
API-ului
create_task cu date invalide.
Hint: Puteți folosi un string pentru completarea câmpului is_done. Folosiți-vă de documentație pentru a valida codul de eroare.