W tej lekcji zaczniemy pokrywać testami cały CRUD i zaczniemy od dwóch pierwszych literek tego akronimu. Pokażę Ci też jak poradzić sobie z powtarzalnymi, wspólnymi elementami żądań.
Dokumentacja do sklepu
Po poprawnym postawieniu aplikacji dokumentację do niej znajdziesz pod localhost/fakestore/dokumentacja/. Tam też znajdziesz np. klucze potrzebne do uwierzytelnienia.
Wersja Javy
W zależności od tego której wersji Javy używasz, mogą się pojawić drobne rozbieżności w sytuacji, w których pobieramy jakąś informację z odpowiedzi metodą get(), a następnie ją „wypluwamy” w konsoli metodą println, np.:
System.out.println(response.jsonPath().get("name"));
Jeżeli nie zadziała Ci to, co pokazuję (będzie się podkreślało na czerwono i po najechaniu zobaczysz „Ambiguous method call”) możesz zamiast get() użyć metody getString():
System.out.println(response.jsonPath().getString("name"));
CRUD: wspólne elementy żądań
CRUD jest podstawową sekwencją działań na obiektach (w naszym przypadku) web service’ów RESTowych. Akronim, który każdy tester pewnie mógłby sobie wytatuować. Utwórz, Odczytaj, Modyfikuj, Skasuj czyli polski CRUD to UOMS 😉
Sprawdzenie tych atomowych czynności zapewnia nam, że podstawowe operacje na danych są obsługiwane w systemie. Bez nich prawdopodobnie nie udałoby się nic bardziej skomplikowanego. W przypadku API pokrycie ich jest szczególnie istotne, bo często na nich potrafi skończyć się logika danego webService’u. Ale pamiętajcie, że to nie tylko akcje są ważne, ale i to na jakich danych są wykonywane . To wybieranie i wymyślanie odpowiednich danych do testów API potrafi być największym testerskim wyzwaniem.
Zanim jednak przejdziemy przez wszystkie literki UOMSa to obiecane wcześniej wyciągnięcie części wspólnej!
Adnotacja BeforeAll
Wykorzystamy jUnitową adnotację @BeforeAll (czyli wykorzystamy metodę wykonywaną raz, przed wykonaniem testów) i w tak oznaczonej metodzie ustawimy po prostu wartości pól klasy RestAssured, które następnie będą wykorzystywane w każdym teście.
Warte osobnego wspomnienia są pola baseURI i basePath. Jeśli chodzi o różnice pomiędzy URI a URL, to odsyłam do wikipedii, albo w ogóle do google.pl. Natomiast najprościej mogę to chyba wytłumaczyć w ten sposób, że pełny URL (taki pod jaki np. strzelamy w Postmanie) składa się z baseURI + basePath + konkretny_adres_aktualnego_zapytania. W naszym przypadku baseURI to po prostu “http://localhost”, basePath to „fakestore/wp-json/wc/v3”, a potrzebujemy do niego dopisać na przykład „products/393” – z takich trzech elementów powstał pełny URL.
Do wyciąganych przez nas parametrów należą jeszcze port (tu mam nadzieję nie ma żadnych wątpliwości) i authentication – wystarczy przekopiować odpowiedni fragment z naszych dotychczasowych zapytań.
W momencie, w którym wiemy, że pola te mają odpowiednie dla nas wartości, to nie musimy ich już podawać w naszych requestach. Dzięki temu z:
Response response = given()
.port(80)
.auth()
.oauth(username, password, "", "")
.when()
.get(url + productsEndpoint + "/" + productCreated);
Robi nam się:
Response response =
when()
.get(productsEndpoint + "/393");
Gdyż wszystkie elementy sekcji given zostały już wcześniej ustawione.
Trochę inaczej jest w przypadku POSTa – tutaj ustawiamy dwa parametry, które pomijamy w GET, czyli contentType i body. Stąd w przypadku tej metody sekcja given się pojawi, jednak musimy w niej przekazać tylko brakujące elementy – czyli ponownie fragment kodu jest krótszy – no i zgodnie z DRY (don’t repeat yourself) nie mamy powtórzeń.
Czy błędem jest wykorzystanie (albo niesie to ze sobą jakieś negatywne skutki?) w tym przypadku metody setup'ującej requesty z adnotacją @BeforeEach zamiast @BeforeAll? Wtedy metoda i zmienne w niej wykorzystywane nie muszą być statyczne.
Hej,
Błędem jako takim - pewnie nie. Ale będzi [...] Całość odpowiedzi widoczna dla kursantów.
Tak jak mówisz przy 2 testach przy korzystaniu z metody z adnotacją @BeforeEach czas testu wyłożył się o sekundę, w sumie już zauważalnie, przy dużej ilości testów wyjdzie to słabo. Co do drugiej części Twojej odpowiedzi, to wychodząc trochę poza Twój kurs i łącząc go z Selenium Eli, myślę o rozwiązaniu, które przez API tworzy obiekt, który potem dalej testuję na froncie. W Selenium korzystam z @BeforeAll bo mam tam niestety testy zależne od siebie i utrzymuję instancję testów przez całą klasę, do której dodałbym teraz chętnie Rest Assured, a z obiektem z klasy WebDriver nie ma opcji na metody statyczne z tego co wyszło mi przy testowaniu tego pomysłu.
Bardzo fajny pomysl, zeby laczyc testy frontu i AP [...] Całość odpowiedzi widoczna dla kursantów.