kontakt@tujestbug.pl

31 października miałem okazję wziąć udział w konferencji testerskiej Tester Summit. Tematem mojej prelekcji było „Nie chodź dwa razy tą samą ścieżką”, gdzie pokazywałem jak usprawnić testy Selenium o testy RestApi.

Prelekcja i mój problem

W ramach tej właśnie prelekcji opisałem na bazie własnego doświadczenia jakich problemów i bolączek doświadczałem w związku z automatyzacją testów w samym Selenium i co ważniejsze, jak udało mi się te problemy rozwiązać.

Jak wiesz testy Selenium, a pewnie także i większość testów bazujących na UI, są podatne na wszelkiego rodzaju zmiany w szacie graficznej strony. Zmiany te wykonywane są na bieżąco, często bez synchronizacji z repozytorium testerskim. W następstwie rano otrzymujemy niedziałający zestaw testów, mimo że aplikacja jest całkiem sprawna.

Dodatkowo testy w samym Selenium są wrażliwe na :

  • wszelkiego rodzaju opóźnienia
  • nieładujące się na czas elementy
  • niekończące się loadery
  • pojawiające się z nienacka pop-upy
  • oraz inne elementy przesłaniające akurat ten jeden element do którego chcemy np. wprowadzić tekst

Szeroko pojęta stabilność jest zatem trudna do osiągnięcia w takich przypadkach i zazwyczaj wiąże się z jakimiś kompromisami. Im więcej masz testów tym większa szansa, że przynajmniej jeden z nich się potknie i znów stracisz poranek na poszukiwaniu nieistniejących bugów😕

Rozwiązanie?

Na pewno jest więcej niż jedno. Można:

  • Uruchamiać ponownie testy, które nie przejdą, czyli tzw. retry.
    🛑 Minusem takiego rozwiązania będzie dodatkowy nakład czasu na wykonywanie testów.
  • Pomijać kroki związane z nawigacją i przy pomocy selenium od razu wczytywać adres URL na którym zamierzamy bezpośrednio wykonywać testy.
    (Dla przykładu twoja-strona-testowa.pl/zakladkaA/obiektB/widokC).
  • Zmodyfikować środowisko testowe, aby jego zachowanie sprzyjało testom automatycznym. Przykładowo można zmieniać częstotliwość wyświetlania pasków ładowania/odświeżania czy nadawać unikatowe identyfikatory elementom webowym itd.

Natomiast moim pomysłem jest zastąpienie części testów Selenium testami Rest-Api, dzięki czemu zyskuję na czasie i stabilności.

❔️Zapytasz – ale które testy pisać w Api, a które w UI? To właśnie mój pomysł, który nazwałem „Nie chodź dwa razy tą samą ścieżką”..

Nie chodź dwa razy tą samą ścieżką

Pomysł polega na rozpisaniu możliwych scenariuszy testowych jako ścieżek, które przechodzi test automatyczny. Kolejnym krokiem jest identyfikacja ścieżek, które są często uczęszczane (wręcz rozdeptane) przez akcje wykonywane na przeglądarce.

Kiedy już wiemy z jakich kroków złożone są nasze testy to otrzymujemy taki obraz:

ścieżki testowania

Każda litera oznacza jeden krok testowy, a każdy scenariusz możemy opisać jako przejście od skrajnego punktu z lewej strony (A) do skrajnego punktu z prawej strony (D,E,G,H).

Teraz pozostaje już tylko tak zmodyfikować testy, aby część kroków wykonać przez testy API. Należy jednak pamiętać, aby wykonać każdy krok chociaż raz przez test Selenium. Daje to nam gwarancję, że jest on wykonywalną akcją po stronie rzeczywistego użytkownika końcowego.

Takie rozwiązanie powinno w teorii przyśpieszyć testy nawet o 50%!

Jesteś ciekawy jak wypadło to na rzeczywistej aplikacji?

Zapraszam Cię do obejrzenia całej prelekcji, gdzie na koniec prezentuję swoje rozwiązanie wraz z pomiarem na rzeczywistej aplikacji w warunkach produkcyjnych.

Link znajdziesz poniżej:

Jeśli podobał Ci się materiał zostaw komentarz, a jeśli nie chcesz, aby ominęły Cię kolejne artykuły z serii o RestAssured to zapraszam na Facebooka oraz na kanał na youtube gdzie znajdziesz materiały video m.in z Postmana czy GitHuba.


0 komentarzy

Dodaj komentarz

Avatar placeholder

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *