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ń.
Komentarze
Nie masz aktywnej subskrypcji. Wykup subskrypcję albo zaloguj się, by móc komentować.