Page Object Model - Jak pisać stabilne i czytelne testy UI?

Na czym polega wzorzec obiektów stron

Ja zwykle zaczynam od prostego pytania: czy ten test da się przeczytać jak opis działań użytkownika? Jeśli odpowiedź brzmi „nie”, to najczęściej problemem jest właśnie brak warstwy pośredniej między testem a interfejsem. Obiekt strony przejmuje wtedy odpowiedzialność za to, jak znaleźć element, kliknąć przycisk, wpisać tekst albo przejść do kolejnego ekranu.

To nie jest tylko elegancki podział kodu. Chodzi o to, żeby testy nie znały szczegółów implementacyjnych, takich jak nazwy klas CSS, kolejność pól w formularzu czy techniczny układ komponentów. Gdy zmienia się UI, poprawiasz głównie jeden plik albo kilka ściśle powiązanych klas, a nie cały zestaw scenariuszy. Dopiero wtedy widać, dlaczego samo trzymanie selektorów w jednym miejscu nie wystarcza.

W dobrze ułożonym projekcie taki obiekt reprezentuje nie całą aplikację, ale jej sensowny fragment: logowanie, koszyk, listę produktów, panel użytkownika. To ważne rozróżnienie, bo nazwa wzorca bywa myląca. Nie każda strona musi dostać osobny byt, ale każdy istotny obszar interfejsu powinien mieć własną, prostą reprezentację.

Repozytorium selektorów to za mało

Najczęstszy błąd, jaki widzę w praktyce, polega na tym, że zespół buduje zwykłe repozytorium elementów i nazywa je POM-em. To jeszcze nie rozwiązuje problemu. Samo ukrycie lokatorów jest przydatne, ale prawdziwa wartość pojawia się dopiero wtedy, gdy obiekt strony zaczyna oferować działania, a nie tylko dane techniczne.

• Dobry obiekt strony mówi: „zaloguj użytkownika”, „wyszukaj produkt”, „otwórz koszyk”.
• Słaby obiekt strony mówi: „znajdź input po selektorze i wpisz tekst”.
• Dobry obiekt strony trzyma selektory w prywatnym zakresie.
• Słaby obiekt strony zmusza test do grzebania w strukturze DOM-u.

W dokumentacji Selenium ten kierunek jest opisany bardzo jasno: testy mają być odseparowane od lokatorów i układu strony, a asercje zwykle powinny zostać po stronie testu. Ja stosuję tę zasadę niemal zawsze, bo inaczej klasa odpowiadająca za ekran szybko zamienia się w przeładowany magazyn logiki. Jedyny sensowny wyjątek to krótka weryfikacja, że strona faktycznie się załadowała i jest gotowa do pracy.

To prowadzi do ważnego wniosku: jeżeli obiekt strony nie upraszcza testu, tylko przenosi tę samą złożoność w inne miejsce, nie ma powodu, żeby go utrzymywać w tej formie. Wtedy lepiej rozdzielić odpowiedzialności jeszcze raz, zanim kod urośnie do nieczytelnego rozmiaru.

Jak zbudować warstwę stron w testach UI

Najczytelniejszy model zaczyna się od podzielenia kodu na warstwy. Test ma wyrażać intencję, obiekt strony ma znać mechanikę interakcji, a komponenty mają wycinać powtarzalne fragmenty interfejsu. To prosty układ, ale tylko wtedy działa dobrze, gdy publiczny interfejs obiektu naprawdę odpowiada temu, co robi użytkownik.

Ja zwykle układam to w pięciu krokach. Najpierw identyfikuję stabilne fragmenty interfejsu, potem opisuję publiczne metody jako akcje użytkownika, następnie chowam selektory do wnętrza klasy. Kolejny krok to zwracanie nowego obiektu strony po nawigacji, a na końcu wydzielam komponenty tam, gdzie ten sam fragment pojawia się w kilku miejscach.

LoginPage
  private locators: username, password, submit

  public methods:
    enterUsername()
    enterPassword()
    submit() -> HomePage

Taki zapis jest celowo prosty. Jeśli nazwy metod zaczynają przypominać techniczne kliknięcia po DOM-ie, to zwykle znak, że API obiektu nie mówi już językiem biznesowym. Z kolei jeśli klasa robi wszystko naraz, warto rozbić ją na mniejsze elementy, zanim stanie się trudna do utrzymania.

Dokumentacja Playwright traktuje model stron jako jeden ze sposobów organizacji większych zestawów testów, co dobrze pasuje do projektów z rosnącą liczbą scenariuszy. To właśnie tam ten wzorzec zaczyna być najbardziej opłacalny, bo oszczędza czas nie przy pierwszym teście, ale przy każdym kolejnym.

Kiedy ten wzorzec daje największą przewagę

W małym projekcie różnica bywa skromna. Gdy masz kilka prostych testów, czasem szybciej jest napisać je bez dodatkowej warstwy abstrakcji. Ale przy kilkudziesięciu albo kilkuset scenariuszach sytuacja zmienia się wyraźnie: każda zmiana selektora, tekstu przycisku albo kolejności kroków zaczyna kosztować, a POM oddaje ten koszt z powrotem w postaci jednego miejsca do poprawki.

• gdy wiele testów korzysta z tych samych ekranów;
• gdy UI zmienia się częściej niż logika biznesowa;
• gdy nad automatyzacją pracuje kilka osób równolegle;
• gdy zależy Ci na czytelnych krokach testu, a nie na rozproszonych wywołaniach `findElement`;
• gdy chcesz ograniczyć liczbę powtórzeń tych samych selektorów w całym repozytorium.

W praktyce największa przewaga pojawia się tam, gdzie zmiana frontendu jest częsta, a testy muszą nadążać bez długich przestojów. Wtedy nawet niewielka poprawka w jednym obiekcie strony potrafi oszczędzić godzinę pracy przy całej paczce scenariuszy. I właśnie dlatego ten wzorzec najlepiej oceniać nie po pierwszym dniu, ale po kilku iteracjach rozwoju aplikacji.

Gdzie zaczyna przeszkadzać

Są też sytuacje, w których rozbudowywanie tej warstwy bardziej szkodzi niż pomaga. Jeśli test jest jednorazowy, krótki albo ma jedynie potwierdzić, że krytyczny ekran się ładuje, pełna architektura obiektów stron może okazać się zwyczajnie za ciężka. Ja nie budowałbym wtedy całej platformy tylko po to, by kliknąć dwa elementy i sprawdzić jeden komunikat.

• Krótki smoke test lepiej napisać prosto niż ubierać go w dużą abstrakcję.
• Silnie dynamiczny interfejs czasem wymaga komponentów albo innego podziału niż klasyczna strona.
• Przerost abstrakcji spowalnia debugowanie i utrudnia szybkie poprawki.
• Ukryte oczekiwania i magiczne waity w obiekcie strony potrafią zamaskować prawdziwy problem.

W takich przypadkach lepsza jest prostota niż elegancja na papierze. Jeśli warstwa abstrakcji nie oszczędza czasu w utrzymaniu, nie ma sensu jej dokręcać. To szczególnie ważne w projektach, w których testy mają wspierać szybkie wydania, a nie zamieniać się w osobny, trudny do zrozumienia framework.

POM a helpery, komendy i testy bez abstrakcji

Żeby dobrze wybrać podejście, trzeba zobaczyć różnicę między kilkoma popularnymi sposobami organizacji testów. Nie każda baza kodu musi wyglądać tak samo, ale każda potrzebuje jasnej granicy między tym, co jest scenariuszem, a tym, co jest techniczną obsługą UI. Ja najczęściej wybieram obiekty stron jako środek ciężkości, a resztę dopasowuję do skali projektu.

Ten wybór nie jest religią, tylko kompromisem między czytelnością, kosztem zmian i tempem pracy. Jeśli zespół myli helpery z pełnym modelem stron, zwykle kończy z kodem, który wygląda na uporządkowany, ale nadal trudno go rozwijać. Z kolei dobrze użyty POM daje najlepszy balans tam, gdzie trzeba utrzymać równowagę między prostotą testu a stabilnością całej warstwy automatyzacji.

Mój filtr przed wdrożeniem w projekcie

Przed wdrożeniem tej architektury sprawdzam pięć rzeczy. To szybki filtr, który pozwala mi ocenić, czy wzorzec faktycznie pomoże, czy tylko dołoży kolejną warstwę do utrzymania.

• Czy obiekt reprezentuje sensowny fragment interfejsu, a nie tylko zbiór przypadkowych elementów?
• Czy publiczne metody opisują intencję użytkownika?
• Czy selektory są ukryte wewnątrz klasy?
• Czy asercje zostały tam, gdzie powinny, czyli w teście?
• Czy powtarzalne fragmenty UI są wydzielone jako komponenty, zamiast dublować się w kilku klasach?

Jeśli odpowiedź na większość tych pytań brzmi „tak”, to wiem, że warstwa obiektów stron realnie pomoże zespołowi. Jeśli nie, wolę uprościć model, zanim zacznie generować dodatkowy koszt. W automatyzacji testów najlepsze rozwiązania nie są najbardziej rozbudowane, tylko takie, które naprawdę zmniejszają liczbę problemów przy kolejnych zmianach aplikacji.