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.

 

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.

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.

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.

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ć