Selenium IDE jako narzędzie służące do nagrywania i uruchamiania testów aplikacji internetowych powstało z inicjatywy Shinya Kasatani już w 2006 roku (sic!). Narzędzie to opiera się o świetną ideę “record & playback”, która w dzisiejszych czasach nie jest już niczym szczególnie nowym. Problemem jednak większości narzędzi dostępnych na rynku, w tym Selenium IDE nie jest bynajmniej przestarzała idea, bo ta wciąż u podstaw jest bardzo elegancka, ale sama jej realizacja. Poniżej przedstawimy największe zarzuty, które można współcześnie postawić Selenium IDE, oraz to w jaki sposób rozwiązujemy je w narzędziu BugBug, aby testy aplikacji przebiegały sprawniej.

Generowanie nieprawidłowych selektorów elementów

Selenium IDE w najnowszej wersji potrafi podczas nagrywania testu wygenerować kilka selektorów elementu, z którym zaszła interakcja. Problem w tym, że narzędzie nie ma możliwości konfiguracji, który typ albo nawet typy selektorów traktować jako domyślne. Co więcej narzędzie preferuje wadliwe podejście generowania selektorów w oparciu o nazwy klas CSS. W tych czasach, gdy coraz popularniejsze staje się CSS-in-JS (za sprawą np. styled-components, które generuje losowe nazwy klas) skutkuje to ostatecznie tym, że wszystkie wygenerowane selektory w ramach sesji nagrywania trzeba samemu zmodyfikować. Efekt – to co powinno zrobić za nas narzędzie i tak mozolnie modyfikujemy ręcznie.

Rozwiązanie problemu zastosowane w BugBug

BugBug podobnie jak Selenium IDE w trakcie sesji nagrywania generuje wiele możliwych selektorów dla elementów, z którymi zaszła interakcja. Różnica jednak polega na tym, że to użytkownik na poziomie konfiguracji swojego projektu decyduje jaka jest hierarchia generowania selektorów:

Dzięki temu w zależności od tego jakie są wymagania w projekcie mamy swobodę i pełną kontrolę nad generowanymi selektorami. Współczesne projekty przy testowaniu bardzo często opierają się o atrybuty data-test czy data-testid, które BugBug preferuje. Jeśli jednak mamy do czynienia ze starszym typem projektów zawsze możemy jako priorytetowe ustawić generowanie selektorów w oparciu o klasy CSS czy ID elementów. Najważniejsze – to użytkownik sam decyduje co jest mu potrzebne zmieniając odpowiednio konfiguracją.

Wygenerowane selektory to dopiero pierwszy etap całego procesu. W trakcie nagrywania testów aplikacji nie mamy pewności co do tego czy selektory są prawidłowe. Dlatego BugBug przy pierwszym uruchomieniu (i po każdej zmianie w teście) dokonuje weryfikacji selektorów i koryguje je jeśli z jakiegoś powodu przy wykonywaniu testu selektor przestał istnieć (np. przez losowe klasy CSS) lub wskazuje na niewłaściwy element. Dzięki zastosowaniu powyższych mechanizmów BugBug maksymalnie ogranicza ingerencję testera w proces wyboru selektorów, a tym samym oszczędza jego cenny czas do tej pory marnotrawiony na ręczne wyszukiwanie i tworzenie selektorów.

Uruchom testy z BugBug już dziś!

Brak aktywnego czekania na elementy (waiting conditions)

Kolejnym, powszechnym problemem w narzędziach record & playback, który występuje również w Selenium IDE jest brak aktywnego czekania na elementy, z którymi ma zajść interakcja. W praktyce wygląda to tak, że jeśli wskazany element znajduje się na stronie (jest w DOM) to Selenium IDE od razu podejmuje próbę interakcji z nim. Element może być w tym czasie niewidoczny, poruszać się, animować, być przykryty innym elementem (loading overlay). W konsekwencji takie zachowanie prowadzi do tworzenia tak zwanych “flaky tests”. Pojęcie to definiuje testy aplikacji, które raz działają, a innym razem nie. To z kolei bardzo często powiązane jest właśnie z brakiem właściwego czekania na element, z którym ma zajść interakcja w ramach testu.

Rozwiązanie problemu zastosowane w BugBug

BugBug mając na uwadze wady istniejących narzędzi problem rozwiązuje u podstaw. Na poziomie konfiguracji projektu istnieje możliwość zdefiniowania warunków oczekiwania (waiting conditions), które muszą zostać spełnione by interakcja z elementem na stronie doszła do skutku:

Globalna konfiguracja projektu jest dziedziczona przez kroki w każdym z testów aplikacji. Istnieje oczywiście również możliwość nadpisania powyższej konfiguracji na poziomie pojedynczego kroku lub dodania dodatkowego warunku jak np. oczekiwanie na przeładowanie strony:

Dzięki zastosowaniu powyższego mechanizmu BugBug stara się zachowywać podobnie jak człowiek, tj. czekać na właściwy moment by dany krok w ramach testu wykonać. Narzędzie potrafi aktywnie czekać gdy:

  • Element animuje się lub zmienia swoje właściwości (CSS animations i transitions): narzędzie wykrywa czy dany element jest animowany i/lub porusza się i oczekuje na zakończenie tego procesu.
  • Element jest niewidoczny: mechanizm BugBuga potafi ocenić czy element jest naprawdę widoczny dla użytkownika i dopiero w takiej sytuacji wykonuje pożądany krok.
  • Element jest przykryty przez inny element.
  • Element jest nieaktywny.
  • Element zmienił swoją pozycję: narzędzie potrafi wykryć zmianę położenia elementu w trakcie wykonywania kroku i ponowić interakcję z nim w takiej sytuacji.

Przy zastosowaniu wszystkich powyższych mechanizmów BugBug sprowadza ryzyko wystąpienia flaky tests do minimum oferując przy tym znacznie stabilniejsze testy względem całej konkurencji rynkowej.

Odtwarzanie kroków w wybrakowany sposób (z użyciem JavaScript)

Selenium IDE jak i większość podobnych narzędzi na rynku wykonuje testy aplikacji w kilku krokach, symulując jedynie fragmentarycznie zachowanie zwykłego użytkownika. W praktyce oznacza to, że nagrane testy mogą zachowywać się w sposób nieprzewidywalny doprowadzając testy do błędów. Najłatwiej problem zobrazować na konkretnym przykładzie.

Krok click na dowolny przycisk “Zaloguj” realizowany w ramach Selenium IDE wykona następujące zdarzenie JavaScript w przeglądarce:

  • click

Rozwiązanie problemu zastosowane w BugBug

Ten sam krok realizowany z wykorzystaniem BugBuga to sekwencja poniższych zdarzeń:

  • mousemove
  • mouseover
  • mouseenter
  • mousedown
  • mouseup
  • click

Powyższa różnica wynika z ograniczeń architektury Selenium IDE, które może jedynie symulować zachowanie użytkownika wykorzystując do tego JavaScript. BugBug dzięki swojej architekturze i wykorzystaniu Chrome DevTools Protocol ma pełną kontrolę nad przeglądarką i tym samym możliwość faktycznego odtworzenia zachowania użytkownika, a nie jedynie fragmentarycznej jego symulacji. Powyższe ma kluczowe znaczenie przy testowaniu współczesnych, mocno rozbudowanych i skomplikowanych aplikacji internetowych (Single Page Applications).

Testy aplikacji nie są uruchamiane w separacji od siebie

Gros narzędzi record & playback na rynku, w tym Selenium IDE ma problem, aby wykonywać testy aplikacji w izolacji od siebie. W konsekwencji prowadzi to do sytuacji kiedy uruchomienie jednego testu wpływa na drugi. Problemem są ciasteczka (cookies) czy mechanizm localStorage, które przeglądarka współdzieli między oknami i kartami. W Selenium IDE trzeba o usuwanie cookies czy localStorage zadbać każdorazowo samemu i z tyłu głowy zawsze pamiętać o tym, że trzeba te dane czyścić między testami.

Rozwiązanie problemu zastosowane w BugBug

Powyższy problem oprócz jego naturalnej uciążliwości prowadzi również bardzo często do wspomnianego już wyżej zjawiska flaky tests. Żeby temu zapobiec w BugBug testy wykonywane są domyślnie w izolacji od siebie przy wykorzystaniu trybu Incognito mode przeglądarki. W ten sposób QA budujący testy nie musi pamiętać o cookies, localStorage i innych mechanizmach współdzielenia danych w przeglądarce. Testy izolowane są przy uruchamianiu zarówno w lokalnej przeglądarce jak i w chmurze.

Oszczędź do 70% czasu pracy testerów oprogramowania

Brak możliwości uruchamiania testów aplikacji w chmurze

Selenium IDE został stworzony wiele lat temu kiedy to “chmura” czy usługi SaaS w ogóle jeszcze nie były rozpowszechnione. W związku z tym, że jako narzędzie jest jedynie dodatkiem do przeglądarki nie oferuje możliwości wykonywania testów w chmurze. Testy stworzone z wykorzystaniem Selenium IDE możemy jedynie wyeksportować do wybranego języka programowania i następnie uruchamiać je w ramach swojej własnej infrastruktury lub wykorzystać do tego komercyjne rozwiązania.

Rozwiązanie problemu zastosowane w BugBug

BugBug od samego początku został zaprojektowany jako narzędzie wspomagające testy aplikacji end-to-end. W związku z tym narzędzie pozwala na:

  • nagrywanie testów i ich swobodną edycję
  • uruchamianie testów lokalnie w ramach przeglądarki użytkownika w celu weryfikacji testów
  • planowanie i uruchamianie testów w chmurze (zarówno przez interfejs WWW jak i narzędzie CLI )
    Więcej o tym, jakie narzędzia powinno mieć dobre oprogramowanie do testowania powiedzieliśmy >>TUTAJ<<

Dzięki temu mamy jedno, zintegrowane narzędzie pokrywające zarówno tworzenie jak i uruchamianie testów.

Brak wsparcia dla wzorca Page Object Model (POM)

Page Object Model (POM) jest sprawdzonym wzorcem projektowym dla testów end-to-end, który pozwala w swobodny sposób na re-użycie kroków w ramach testów i tym samym upraszcza ich utrzymanie. Wzorzec ten opiera się na tworzeniu grup kroków reprezentujących strony testowanej aplikacji internetowej jako tzw. Page Object. Dzięki temu tworząc Page Object “Logowanie” możemy go wykorzystywać wielokrotnie w każdym teście, który logowania wymaga. W przypadku zmiany formularza logowania test naprawiamy w jednym miejscu i wszystkie testy bazujące na Page Object “Logowanie” w konsekwencji również są naprawiane.

Selenium IDE niestety nie wspiera tworzenia testów w oparciu o Page Object Model. Każdy test posiada swoje, odrębne kroki. Jeśli posiadamy wiele testów, których pierwszym etapem jest logowanie to w momencie gdy to logowanie z jakiegoś powodu przestaje działać musimy je naprawić we wszystkich testach osobno.

Rozwiązanie problemu zastosowane w BugBug

BugBug został stworzony z myślą o wsparciu wzorca Page Object Model od samego swojego początku. Narzędzie pozwala w swobodny sposób na grupowanie kroków i tworzenie z nich reużywalnych komponentów. Co więcej – naturalną konsekwencją takiego podejścia staje się możliwość wizualizacji zaprojektowanych w ten sposób testów na jednym, spójnym grafie. Reprezentując w ten sposób wszystkie testy mamy jasny ogląd na to, które ścieżki biznesowe w ramach projektu są pokryte testami end-to-end.

Podsumowując

BugBug jest tym, czego potrzebujesz?

Niezawodne, kompleksowe oprogramowanie, które usprawnia pracę testerów i programistów.

Zamów newsletter