Powrót do strony głównejCypressAnywhere.ioO autorze
Powrót

Testy API - metoda GET

Testy automatyczne opisane w tym blogu są zorganizowane w następującej formie:

  1. Przypadków testowych wraz z krokami (w uproszczonej formie)
  2. Linku do miejsca w repozytorium kodu, w którym znajduje się implementacja testów automatycznych
Dzięki temu, lektura oraz nauka, będą przyjemniejsze. W każdym momencie możliwe będzie, ściągnięcie skonfigurowanego projektu Cypress na swój komputer oraz uruchomienie testów lokalnie. Będę również dbała o to, aby przykłady były na bieżąco aktualizowane, gdy właściciel testowanej aplikacji, dokona zmiany niekompatybilnej wstecz.

Czym jest testowanie API?

Odpowiedzi znajdziemy wiele, ale w prostej do przyswojenia definicji, testowanie API, możemy określić jako wysyłanie żądania do serwera i potwierdzenie, czy otrzymana odpowiedź jest poprawna. Żądanie, które ma nam zwrócić odpowiedź, najczęściej dane w formacie JSON. Gdy usłyszałam zdanie "Przetestuj API", po chwili otrzymałam link do strony z dokumentacją API. By sprawdzić, czy API działa, skorzystałam z narzędzia Postman, które służy między innymi do manualnego przetestowania API i jest bardzo popularne wśród testerów oprogramowania. Do wyboru mamy kilkanaście metod testowania API. Najczęściej używane to: GET, POST, PUT, PATCH, DELETE. Metodą, którą wybrałam do pierwszego posta na temat testowania API, jest GET. Po potwierdzeniu w Postmanie tego, że API działa, przystąpiłam do napisania testów automatycznych. Poniżej link do dokumentacji testowanego API:https://jsonplaceholder.typicode.com

1. Przypadek testowy: Testowanie endpointa /posts/{id} - metoda GET

Tym razem bardziej zrozumiałe będzie, jeżeli najpierw obejrzymy kod przypadku testowego, następnie przejdziemy do kolejnego etapu posta. Kod testu znajduje się pod tym adresem Kod testu api

  • Krok 1: Pobierz z API pojedynczy post

Opis kodu

const testData = Array.from({ length: 20 }, (_, i) => i + 1);Na potrzeby testów, stworzyłam dane testowe w postaci tablicy, która zawiera 20 elementów. i + 1 - zwiększa numer kolejnego posta o 1, do uzyskania 20 postów. Dzięki temu, wykonujac pętlę po elementach, przeprowadzimy test 20 kolejnych postów, co bardziej zwiększa szansę na znalezienie błędu, niż przetestowanie tylko jednego posta. Można się spierać czy ma to sens, jednak z doświadczeń bardziej doświadczonych developerów wiem, że na środowisku testowym pracują różni użytkownicy, w tym testerzy manualni, którzy potrafią wprowadzać najróżniejsze przypadkowe dane do aplikacji, w rezultacie czego np. 1 testowy element, używany przez testerów automatyzujących, może zawierać poprawne dane, zatem testy zawsze zakończą się sukcesem, a mimo to w innych elementach, użyto danych, które z założenia są błędne i API nie powinno nigdy dopuścić ich wprowadzenia. Oczywiście nikt tych danych nigdy nie przetestował, bo testowano tylko jeden element. Można stworzyć lepsze założenia testowe, jednak na potrzeby nauki, ten przykład jest wystarczający.cy.request(`https://jsonplaceholder.typicode.com/posts/${item}`).as("apiRequest")

cy.request to metoda Cypressa do komunikacji z API, która przyjmuje jako argument adres endpointa. Metoda as("apiRequest") tworzy alias o nazwie @apiRequest ,pod którym nasz request będzie dostępny.

Tak przygotowany request, możemy wysłać do API, jak wcześniej ustaliliśmy, metodą GETconst response = cy.get("@apiRequest");

Teraz możemy użyć danych z odpowiedzi API. Możemy to zrobić za pomocą metody .should()response.should((res) => {W zmiennej res znajduje się nasza odpowiedź z API.

Teraz wykonujemy testy, czyli używamy odpowiednich asercji, aby sprawdzić poprawność danych zwróconych przez API.

Najpierw sprawdzimy podstawowe informacje o odpowiedzi API: czy dane są w odpowiednim formacie oraz czy kod statusu jest oczekiwanym

Asercja 1

Na początku sprawdzamy, czy nasze dane są w formacie JSONexpect(res.headers["content-type"]).to.include("application/json");

Asercja 2

Następnie sprawdzamy, czy API zwróciło kod statusu o wartości 200 - OK. Statusy odpowiedzi z API mogą zawierać wartości dostępne dla kodów statusu odpowiedzi HTTPexpect(res.status).to.eq(200);

Przypisanie res.body do stałej

Właściwe dane, które nam zwróci API, znajdują się w polu body, dlatego aby łatwiej nam się pisało, przypiszemy je do stałej. Dzięki temu, zamiast w każdej linii pisać res.body, napiszemy responseBodyNie jest to konieczny zabieg, jednak przyjął się jako jedna z zasad pisania czystego kodu.const responseBody = res.body;

Teraz możemy sprawdzić, czy właściwe dane są poprawne. Jako, że nie posiadamy specyfikacji wymagań, przyjmiemy założenia wynikające z logiki i doświadczenia zawodowego.

Asercja 3

Sprawdzamy, czy pole userId jest liczbąexpect(responseBody.userId).to.be.a("number");

Asercja 4

Sprawdzamy, czy pole userId jest większe niż 0expect(responseBody.userId).to.be.greaterThan(0);

Asercja 5

Sprawdzamy, czy pole id jest liczbąexpect(responseBody.id).to.be.a("number");

Asercja 6

Sprawdzamy, czy pole id jest większe niż 0expect(responseBody.id).to.be.greaterThan(0);

Asercja 7

Sprawdzamy, czy pole title jest ciągiem znakówexpect(responseBody.title).to.be.a("string");

Asercja 8

Sprawdzamy, czy pole title ma długość, co najmniej 5 znakówexpect(responseBody.title).to.have.length.of.at.least(5)

Asercja 9

Sprawdzamy, czy pole body jest ciągiem znakówexpect(responseBody.body).to.be.a("string");

Asercja 10

Sprawdzamy, czy pole body ma długość, co najmniej 50 znakówexpect(responseBody.body).to.have.length.of.at.least(50);

To wszystko...

Pierwszy endpoint został pokryty testami 😊

2. Przypadek testowy: Testowanie endpointa /posts - metoda GET

Również tym razem, zacznijmy od przyjrzenia się kodowi pod tym adresem Kod testu api

  • Krok 1: Pobierz z API 100 postów

Opis kodu

W odróżnieniu od poprzedniego kroku, tym razem nie będziemy wykonywać pętli po tablicy danych testowych, ale wykonamy pętlę po tablicy 100 postów, zwróconych przez endpoint. Zatem zaczynamy.cy.request(`https://jsonplaceholder.typicode.com/posts`).as("apiRequest")

cy.request to metoda Cypressa do komunikacji z API, która przyjmuje jako argument adres endpointa. Metoda as("apiRequest") tworzy alias o nazwie @apiRequest ,pod którym nasz request będzie dostępny.

Tak przygotowany request możemy wysłać do API, jak wcześniej ustaliliśmy metodą GETconst response = cy.get("@apiRequest");

Teraz możemy użyć danych z odpowiedzi API. Możemy to zrobić za pomocą metody .should()response.should((res) => {W zmiennej res znajduje się nasza odpowiedź z API.

Teraz wykonujemy testy, czyli używamy odpowiednich asercji, aby sprawdzić poprawność danych zwróconych przez API. Ten przypadek jest bardzo podobny do poprzedniego, niech to Was nie zmyli. W dalszym ciągu, testujemy posty tego samego typu.

Najpierw sprawdzimy podstawowe informacje o odpowiedzi API: czy dane są w odpowiednim formacie oraz czy kod statusu jest oczekiwanym

Asercja 1

Na początku sprawdzamy, czy nasze dane są w formacie JSONexpect(res.headers["content-type"]).to.include("application/json");

Asercja 2

Następnie sprawdzamy, czy API zwróciło kod statusu o wartości 200 - OK. Statusy odpowiedzi z API mogą zawierać wartości dostępne dla kodów statusu odpowiedzi HTTPexpect(res.status).to.eq(200);

Przypisanie res.body, czyli danych które zwrócił endpoint do stałej

const responseBody = res.body;

Asercja 3

Jak już wiemy, endpoint zwróci nam tablicę 100 postów. Sprawdzamy, czy stała responseBody ma długość równą 100.expect(responseBody.length).to.eq(100)

Teraz wykonujemy pętle po elementach tablicy i sprawdzamy, czy dane każdego posta są poprawne. W zmiennej item przy każdej iteracji pętli, dostępny jest jeden post. Jako, że nie posiadamy specyfikacji wymagań, przyjmiemy założenia wynikające z logiki i doświadczenia zawodowego.responseBody.forEach((item) => {

Asercja 4

Sprawdzamy, czy pole userId jest liczbąexpect(item.userId).to.be.a("number");

Asercja 5

Sprawdzamy, czy pole userId jest większe niż 0expect(item.userId).to.be.greaterThan(0);

Asercja 6

Sprawdzamy, czy pole id jest liczbąexpect(item.id).to.be.a("number");

Asercja 7

Sprawdzamy, czy pole id jest większe niż 0expect(item.id).to.be.greaterThan(0);

Asercja 8

Sprawdzamy, czy pole title jest ciągiem znakówexpect(item.title).to.be.a("string");

Asercja 9

Sprawdzamy, czy pole title ma długość conajmniej 5 znakówexpect(item.title).to.have.length.of.at.least(5)

Asercja 10

Sprawdzamy, czy pole body jest ciągiem znakówexpect(item.body).to.be.a("string");

Asercja 11

Sprawdzamy, czy pole body ma długość conajmniej 50 znakówexpect(item.body).to.have.length.of.at.least(50);

To wszystko...

Drugi endpoint został pokryty testami 🚀

Przydatne linki powiązane z tym postem:

Dokumentacja Cypress - asercje

Kody testów, znajdują się pod adresami

Kod testu api - przypadek 1

Kod testu api - przypadek 2