Table of Contents

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:

Abordări în Testarea de Integrare

Există două abordări principale:

  1. Abordarea Big Bang
  2. Abordarea Incrementală

1. Testarea de Integrare Big Bang

În această abordare, toate modulele sunt integrate și testate simultan, ca un întreg.

Avantaje:

Dezavantaje:

Recomandări:

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:

Dezavantaje:

Testare de Integrare Top-down vs. Bottom-up

Testarea incrementală poate fi împărțită în:

  1. Bottom-up: Se testează mai întâi componentele low-level (fundamentale), apoi cele high-level
  2. Top-down: Se începe cu componentele high-level (complexe), apoi cele low-level
  3. Hibrid: Se combină cele două abordări

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:

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:

3. Testarea Hibridă (Sandwich)

Se combină top-down și bottom-up.

Avantaje:

Dezavantaje:

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

Dacă folosiți un fork al repo-ului, asigurați-vă că este sincronizat cu repo-ul principal.

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:

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.

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).

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.

Î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.

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.

Hint: Puteți folosi un string pentru completarea câmpului is_done. Folosiți-vă de documentație pentru a valida codul de eroare.