Redakcja
Aby w pewien sposób ustrzec się przed takimi problemami i ułatwić implementację testów, powinniśmy zastosować wzorzec projektowy, który nam w tym pomoże. Jednym z takich wzorców jest Page Object Pattern (POP), który wprowadza do testów pewną ideologię mającą na celu odizolowanie stron, widoków i elementów na stronie od samych testów. Testy stają się czytelniejsze, łatwiejsze w implementacji oraz prostsze w utrzymaniu.
Naszą pracę z implementacją wzorca rozpoczniemy od testu logowania… bo przecież, to od tego wszystko się zaczyna.
Gdy sięgniemy pamięcią do naszych starszych skryptów lub początków naszej pracy z automatami okazałoby się, że taki test mógłby wyglądać tak:
Można zauważyć, że w teście pojawiły się akcje wykonywane na elementach naszej strony oraz finalna asercja sprawdzająca czy znaleźliśmy się na pożądanej stronie. Niby wszystko działa i jest ok, ale problemy pojawią się, gdy logowanie będziemy chcieli wykorzystać w kilku testach.
Tutaj można zauważyć, że obie metody testowe wykorzystują te same akcje, więc w przypadku, gdy sposób logowania się zmieni, albo id któregoś obiektu zostanie zmienione, wszystkie testy będą wymagały aktualizacji. Zmiany będą musiały być naniesione w testach, w których wykorzystane jest logowanie – a ich może być wiele. I właśnie tutaj przychodzi z pomocą POP. W naszym kodzie oddzielamy akcje na elementach strony od testów tworząc pewną odizolowaną strukturę projektową. Dzięki rozdzieleniu tych elementów projektu możemy łatwiej zarządzać każdym z nich. W większości przypadków stworzymy osobne katalogi dla elementów projektu.
Jako Pages rozumiemy wszystkie modele naszych stron, a jako Tests - testy, które będą operowały na tych modelach.
Tak to może wyglądać w kodzie naszego testu:
A tak może wyglądać przykładowy model naszej strony:
W modelu strony można zauważyć, że do lokalizacji elementów zostało użyte Page Factory – jedna z możliwości dodatkowego wsparcia wzorca POP.
Mimo iż pokazany przykład jest bardzo prosty, a wręcz trywialny, prawdopodobnie większość z Was zauważy, jak POP zmienia nasz projekt testowy. Dzięki takim zmianom mamy możliwość wielokrotnego wykorzystania metod operujących na elementach strony, a w przypadku gdy coś ulegnie zmianie na naszej stronie ingerencja w kod będzie minimalna, ponieważ będzie dotyczyła w większości przypadków, jednej metody w klasie modelu zmienionej strony.
Jeżeli chcielibyście się dowiedzieć więcej lub poznać bardziej zaawansowane techniki testowania automatycznego zapraszamy na nasze praktyczne szkolenia, które nauczą Was jak dobrze testować oprogramowanie.
Najbliższe terminy szkoleń:
27 września Java dla testerów oprogramowania, Kraków
28 - 29 września Selenium WebDriver dla początkujących, Kraków
