• Przejdź do głównej nawigacji
  • Przejdź do treści
  • Przejdź do głównego paska bocznego
  • Przejdź do stopki
Testelka.pl

Testelka.pl

Testelka.pl - o technologiach w testowaniu oprogramowania

  • Kursy
    • DARMOWY: Java dla testerów
    • Selenium w Javie
    • Selenium w C#
    • Testy API w REST Assured
    • Selektory CSS
    • XPath
  • Materiały na raz
  • Blog
  • O Eli
  • Zaloguj się
  • DOŁĄCZ

API w REST Assured 15. Organizacja projektu testowego

Strona główna > Kursy > Testy API w REST Assured > API w REST Assured 15. Organizacja projektu testowego

Temat na tę lekcję, to organizacja projektu testowego. Pokażę Ci jak można trochę inaczej poubierać w klasy nasze testy.

Dokumentacja do sklepu

Po poprawnym postawieniu aplikacji dokumentację do niej znajdziesz pod localhost/fakestore/dokumentacja/. Tam też znajdziesz np. klucze potrzebne do uwierzytelnienia.

 

Organizacja projektu testowego

Dotychczas korzystaliśmy z podstawowej klasy testowej, która przechowywała podstawowe ustawienia dotyczące naszego API. Rozszerzaliśmy ją konkretnymi klasami testowymi, w których już wykonywaliśmy konkretne działania na API. Korzystaliśmy z notacji RestAssured, która w ramach pojedynczego zapytania pozwala od razu stosować też asercje.

Czy dotychczasowe podejście jest złe?

Nie (ale tak naprawdę to zależy). Jeśli mamy niewielki zestaw testów, to może się okazać, że narzut na przygotowanie dodatkowej struktury nigdy się nie zwróci. Wtedy mamy ładnie i porządnie, ale potrzebowaliśmy na to dużo czasu. Z drugiej strony, jeśli mamy dużo testów, to za każdym razem, kiedy przyjdzie nam w nich coś zmieniać będziemy pluli sobie w brodę, że nie zaprojektowaliśmy naszego „frameworka” lepiej.

Czemu piszę „framework” w cudzysłowie? Dlatego, że dla mnie frameworkiem jest REST Assured, Selenium jest bardziej biblioteką, choć twórcy używają hasła framework. My natomiast po prostu budujemy projekt testów automatycznych i będziemy się dziś zastanawiać nad jego optymalną organizacją.

Ile projektów, tyle podejść

To, co jest bardzo ważne, to fakt, że nie istnieje jedno uniwersalne podejście. Tak jak wśród konkretnych implementacji Page Object Model w Selenium znajdziecie różniące się podejścia, tak tym bardziej jeśli chodzi o API nie ma Świętego Graala. Polecam więc wykonać eksperyment myślowy polegający na rozrysowaniu sobie na kartce różnych możliwych organizacji/podziałów i zastanowieniu się co jest dla Was najbardziej intuicyjne, co jest dopasowane do Waszego projektu. Czy np. chcecie korzystać z klas reprezentujących obiekty, żeby łatwiej sięgać do ich pól, czy wystarczą Wam niezdeserializowane odpowiedzi API? Przedstawiony przykład traktujcie więc jako… przykład. Jedną z wielu możliwości. Mam nadzieję, że zachęcę Was do zastanowienia i własnych pomysłów.

Organizacja projektu testowego: bazowa konfiguracja

Wyobraźmy sobie, że stworzę coś a’la Page Object Model, tylko per endpoint. Zaczniemy więc od bazowej konfiguracji wspólnej dla wielu endpointów: tak powstanie abstrakcyjna klasa BasicEndpointConfiguration.

Ukryta treść

Nie masz aktywnej subskrypcji. Wykup subskrypcję albo zaloguj się, by móc zobaczyć pełną lekcję.

Trafia tu to, co wcześniej znalazło się w bazowej klasie testowej. Stworzyliśmy sobie też ale też magiczne pole „lastResponse”: będziemy z niego korzystali w naszych testach i przechowywali tam (jak sama nazwa wskazuje) ostatni otrzymany z API response.

Dodałem tam też metodę zwracającą to pole i coś, z czego korzystamy w każdym teście, czyli metodę zwracającą ostatni status code. Skrócimy sobie dzięki temu trochę sposób sięgania po niego. Na filmie pokazuję jak najpierw używam dłuższej wersji, sięgając w teście do statusCode, a potem dopisuję tę metodę, żeby skrócić zapis.

Organizacja projektu testowego: klasa reprezentująca endpoint

Tak zbudowaną klasę możemy rozszerzyć już konkretnym opisem jakiegoś endpointu, a będzie to endpoint związany z produktami.

Ukryta treść

Nie masz aktywnej subskrypcji. Wykup subskrypcję albo zaloguj się, by móc zobaczyć pełną lekcję.

Ta klasa na razie może mieć jedno pole (String enpoint). Wiem, że pierwszy test jaki będę chciał stworzyć będzie po prostu pobieraniem obiektu. Dlatego od razu uzupełniam klasę o metodę getProduct. Zwróci ona nasz javowy obiekt produkt (pobrany z API) ale też uzupełni lastResponse (zadeklarowane w klasie bazowej) o wszystko, co dostanie w odpowiedzi.

Organizacja projektu testowego: test

Teraz jesteśmy gotowi, by stworzyć test.

Ukryta treść

Nie masz aktywnej subskrypcji. Wykup subskrypcję albo zaloguj się, by móc zobaczyć pełną lekcję.

W teście musimy sobie stworzyć obiekt naszej nowej klasy ProductsEndpoint i korzystając z jego (jedynej jak na razie) metody pobierzemy produkt o zadanym ID.
Mając produkt i wiedząc, że wysłanie zapytania do API uzupełniło pole lastResponse, możemy wykonać asercję zarówno na ostatnim kodzie odpowiedzi (ten powinien wynieść 200), jak i na nazwie produktu, który spodziewamy się pobrać

Reader Interactions

Komentarze

Nie masz aktywnej subskrypcji. Wykup subskrypcję albo zaloguj się, by móc komentować.

Pierwszy Sidebar

LEKCJE W KURSIE

  • Lokalna aplikacja do testów za pomocą LocalWP lub XAMPP
  • Czym jest API?
  • Pierwsze zapytanie do API
  • Pierwszy test API - metoda GET
  • Tworzenie obiektów w API - metoda POST
  • Zadanie: tworzenie i pobieranie obiektów
  • Usuwanie i zmiana obiektów - metody DELETE i PUT
  • CRUD: wspólne elementy żądań
  • CRUD: PUT i PATCH oraz niezależność testów
  • Jak szperać w JSONie?
  • Zadanie: żądania w pętli
  • Asercje
  • Serializacja i deserializacja
  • Zadanie: serializacja i deserializacja
  • Organizacja projektu testowego
  • Zadanie: organizacja projektu testowego

Footer

Elzbieta Natalia Sadel
Calle Marzo 9 1 D
41009 Sevilla
Hiszpania
NIF: Y7882076J

Zostań trenerem!

Regulamin
Polityka prywatności
Polityka wsparcia w ramach członkostwa

Koszulki i torby dla testerów

Pomoc
Kontakt

Poskładane z 💛 przez Automatela.pl

Ta strona korzysta z ciasteczek aby świadczyć usługi na najwyższym poziomie. Dalsze korzystanie ze strony oznacza, że zgadzasz się na ich użycie.ZgodaNie wyrażam zgodyPolityka prywatności