Porządki
Po części wpisów, w których zaczęliśmy tworzyć testy, przyszedł czas na porządki. Pierwszym aspektem aby zacząć pracować nad page object model, z którym zrobimy porządek to strona, na której wykonujemy testy, zmienimy ją na: (http://automationpractice.com/index.php).
Drugim aspektem, który wprowadzi większy porządek w nasze testy to zastosowanie podejścia Page Object Model, o którym możesz przeczytać poniżej.
Zalety Page Object Model
- Większa czytelność testów
- Łatwiejsze poprawianie zmian w przypadku ewentualnych zmian
- Zmniejszenie duplikacji kodu
Page Object Model
Czym więc tak naprawdę jest page object model?
Page Object — Jest to nic innego jak wykorzystanie programowania obiektowego i reprezentacja stron czy też komponentów za pomocą obiektów.
Tłumacząc to prościej (wersja page object model uproszczona):
- Tworzymy klasę, która reprezentuje dany widok na stronie (przykładowo strona główna).
- Definiujemy w niej elementy strony (elementy, na których będziemy operować — przyciski, pola do wpisywania tekstu, inne istotne elementy — Page Factory).
- Używamy tak zbudowanych elementów do stworzenia metod takich jak logowanie do danej strony czy dodanie produktu do koszyka.
- Tworzymy taki obiekt w naszej klasie z testem — pozwala nam to używać tej samej metody w wielu testach bez potrzeby duplikacji kodu i pisania tego samego kilka/kilkanaście razy.
Same elementy definiowaliśmy już w poprzednich testach. Tak samo operowaliśmy na metodach, które oferuje Selenide. Teraz wszystkie te elementy połączymy w całość.
W tym wpisie nie chcę Cię zalewać masą teorii odnośnie page object model. Bardziej zależy mi na tym, żebyś zrozumiał sam koncept i zaimplementował ten przykład praktycznie. : )
Page Object Model w praktyce
Pierwszym krokiem, od jakiego zaczniemy, jest usunięcie naszej pierwszej klasy testowej, której używaliśmy w poprzednich częściach. Kasowanie swojego kodu nie zawsze jest przyjemne, ale pozwoli nam to napisać jeszcze lepsze testy. 😉
Następnym elementem będzie mała zmiana struktury projektu.
Następnym krokiem będzie stworzenie paczki na nasze klasy reprezentujące stronę. Zrobimy w katalogu src>java> następnie prawy przycisk myszki. Wybieramy new>package. Nazwijmy ją pageObject.
Napiszmy naszą pierwszą klasę
Dzisiejsze zadanie z treningiem page object model zacznijmy od prostego zadania, jakim będzie wysłanie formularza kontaktowego.
Zaczynamy od stworzenia klasy w naszej paczce z widokiem formularza kontaktowego.
Prawy przycisk myszki w naszej paczce page object > new > java class > ContactUsPage.
Teraz kiedy mamy naszą klasę musimy zdefiniować elementy, na których mamy zamiar pracować. Robimy to za pomocą SelenideElement następnie definiujemy tak samo jak w naszych pierwszych testach elementy.
Różnica, jaka jest w porównaniu do naszych pierwszych testów to fakt, że każdemu z nich nadajemy nazwę. Powinna być ona charakterystyczna oraz unikatowa. Istotnym aspektem jest również any jasno opisywała co to za element. Z czasem zobaczysz, że niejasno opisane elementy to jedna z gorszych rzeczy, jakie może się przytrafić.
Przez niejasne opisy może się zdarzyć, że po jakimś czasie kiedy będziemy chcieli dopisać kolejne metody, trzeba będzie sprawdzać ponownie na stronie co dane elementy oznaczają. W skrócie warto zainwestować czas w dobre opisy elementów.
goTo — wejście na dany widok
Pamiętasz jak w poprzednich częściach, wchodziliśmy na stronę, gdzie wykonywaliśmy testy? Teraz napiszemy do tego specjalną metodę. Dodanie jej do widoków, nad którymi będziemy pracować spowoduje, że nie zawsze nasz test będzie zaczynał się od tej samej strony głównej. Przyśpieszy to wykonywanie naszych testów oraz zwiększy ich niezawodność.
Akcje na naszych elementach
Czas napisać metody, które będą odpowiadać akcjom, jakie będziemy wykonywać na stronie. Tutaj uwaga z mojej strony, pisanie zbyt „atomowych” (małych) metod nie jest często optymalnym rozwiązaniem. Dlatego warto się zastanowić czy nie da się złożyć z naszych elementów większych akcji.
Pierwszym zadaniem, jakie widać na naszej stronie kontaktowej to fakt, że będziemy musieli użyć kolekcji Selenide, o których wspominałem we wpisie drugim. Potrzebna nam ona będzie do wybrania odpowiedniego Subject Heading.
Zacznijmy od stworzenia mechanizmu do wybrania odpowiedniej opcji. Kolekcja ta zwróci nam wszystkie 3 dostępne opcje.
Wyślijmy nasz formularz
Ostania metoda, jaka nam się dziś przyda, będzie miała za zadanie wysłać nasz formularz. Tak jak wspominałem, nie jest ona atomowa (mała). W zamian jedną metodą możemy wysłać cały formularz z podstawowymi danymi.
Jak widzimy, wykorzystujemy w niej wpisywanie wartości w pola oraz naszą kolekcję.
Jak sprawdzić, czy formularz wysłał się poprawnie — tworzenie asercji!
Żeby upewnić się, że nasz formularz został poprawnie wysłany, musimy wykorzystać asercję. Wizualnie na naszej stronie wygląda to tak, że po wysłaniu formularza otrzymujemy komunikat, że wysyłka się powiodła.
Pisanie asercji można zrobić na dwa sposoby. Możemy wykonywać asercję i budować je w naszych klasach z widokiem, drugie rozwiązanie to wykonywać asercje w klasach z testami. Ja jestem zdecydowanie fanem pierwszego rozwiązania, natomiast jest to kwestia preferencji.
Czas napisać test
Skoro w klasie z naszym widokiem zdefiniowaliśmy już wszystkie na ten moment niezbędne elementy możemy przystąpić do napisania testu korzystając z page object model.
Stwórzmy zatem paczkę tests a w niej klasę ContactFormTest.
Teraz zostało jedynie stworzenie naszego obiektu, który reprezentuje stronę, na której będziemy operować.
To, co musimy stworzyć teraz to nasz pierwszy test wykorzystując page object model. Dodajemy naszą annotace testNG @test i nazywamy nasz test.
Następnym krokiem jest użycie naszego obiektu i dostępnych w nim metod.
- Zaczynamy od goTo które przeniesie nas na odpowiednią stroną z formularzem kontaktowym
- Następnie sendFormWithBasicData gdzie przekazujemy nazwę zgłoszenia, nasz adres e-mail oraz treść samego zgłoszenia
- Ostatnim krokiem jest wykonanie asercji, która sprawdzi, czy faktycznie tekst po wysłaniu formularza jest taki jak powinien być
Podsumowanie
Jak widzisz takie napisanie testu powoduje, że jest on wyraźnie czytelniejszy od wcześniejszego rozwiązania gdzie wszystko definiowaliśmy w jednym miejscu. Takie rozwiązanie wprowadza też większą czytelność i pozwala na re używanie naszego kodu.
Większość testów, jakie widziałem piszę się z wykorzystaniem page object model i można powiedzieć, że jest to standard jeśli chodzi o pisanie testów na ten moment.
Jeśli nie chcesz też przegapić następnych wpisów, zapraszam Cię do zapisywania się na newsletter. Będę Cię informował o nowych wpisach dotyczących automatyzacji i testowania oprogramowania.
Całość kodu można pobrać pod adresem: https://github.com/Project-Quality/Selenide-Project/releases/tag/1.1
Photo by Safar Safarov on Unsplash
