Selenium jest narzędziem pozwalającym pisać testy automatyczne aplikacji webowych. Dzięki szerokiej gamie możliwości, sporej społeczności i kompatybilności od lat cieszy się dużą popularnością. Na oficjalnej stronie można znaleźć wiele materiałów: https://www.seleniumhq.org/.

Foto: moje, 2016

Dobre praktyki w automatycznych testach w Selenium:

• Podstawowa zasada – używanie aktywnego czekania (WebDriverWait, wait.Until, ImplicitlyWait itd.) zamiast Thread.Sleep, który spowalnia testy, nie dając jednocześnie gwarancji, że zastosowana przerwa jest odpowiednio długa (jest wiele artykułów na ten temat w sieci).
• Wyszukiwanie elementów na stronie za pomocą selektorów CSS (By.CssSelector) lub identyfikatorów ID lub name (By.Id, By.Name) – taka metoda jest o niebo szybsza niż wyszukiwanie przez XPATH.
• Używanie wzorca Page Object.

Dobre praktyki w testach automatycznych

Oraz kilka dobrych praktyk, które mogą być stosowane ogólnie w testach, nie tylko Selenium:

• DRY – Don’t Repeat Yourself – niepowielanie tego samego kodu poprzez tworzenie np. zestawów funkcji bibliotecznych, dobre rozplanowanie architektury testów, korzystanie z dostarczanych przez framework metod jak Test Setup, Teardown (np. ustawienie przeglądarki przed testami, zamknięcie przeglądarki po testach).
• Behaviour Driven Testing – testy będą „bliżej autentycznego użytkownika”.
• Logowanie błędów! Bardzo przydatne w przypadku testów uruchamianych na środowiskach Continuous Integration, gdzie jeśli testy nie mają logów, jedyną informacją, jaką dostarczą będzie „test nie przeszedł, coś nie działa”. Warto logować ścieżkę wykonanych akcji wraz z parametrami metod oraz informacje o środowisku na którym uruchomiono testy: system, przeglądarka, baza danych itd., godzina – a nuż błąd pojawia się na przykład pomiędzy 23 a 1 dnia następnego?, itd.
• Screenshoty – jeżeli jest taka możliwość (a w Selenium jest) – stanowią wspaniałe źródło informacji o błędach. Nie wszystko da się wyczytać z logu – informacja typu „nie da się kliknąć kontrolki x” niewiele mówi – tymczasem „obraz wyraża więcej niż tysiąc słów”, a na screenie dokładnie widać, co się wydarzyło.

Podejście do testów automatycznych

Może się wydawać (nadal!), że testy są niepotrzebne, są stratą czasu. Tymczasem są one w stanie wykryć defekty już na bardzo niskim poziomie (testy jednostkowe).

Jeżeli aplikacja boryka się z problemami dużego długu technicznego, złej architektury a klasy cechują się wysokim sprzężeniem, próby modyfikacji aplikacji „na siłę”, byle tylko pokryć ją testami mogą niestety narobić więcej szkody, niż pożytku. W takim przypadku lepiej sprawdzi się metoda małych kroków.

Implementując nowe funkcjonalności w aplikacji warto rozważyć piszanie testów jednostkowych tylko do nowych partii aplikacji (TDD). Przymierzając się natomiast do dużych zmian w całej aplikacji warto przygotować jak najwięcej wysokopoziomowych testów czarnoskrzynkowych (funkcjonalnych, integracyjnych). Nawet jeśli ich implementacja byłaby kosztowna w sensie czasowym lub finansowym, warto to zrobić. Optymalnym rozwiązaniem jest zautomatyzowanie owych testów. Minimalnym – spisanie wszystkich wymagań stawianych aplikacji (np. w formie proponowanej przez BDD).

Inspirację do tworzenia nowych przypadków testowych można czerpać również z błędów zgłaszanych przez użytkowników. To bardzo dobre źródło informacji o tym, w jaki sposób użytkownicy naprawdę używają aplikacji. Dobrze zgłoszony błąd zawiera pełną ścieżkę czynności potrzebnych do zreprodukowania błędu. Po jego naprawieniu, warto ją zautomatyzować.