API w REST Assured 8. CRUD: wspólne elementy żądań

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

System.out.println(response.jsonPath().get("name"));

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