Czy POM to jedyny sposób na organizację kodu w testach Selenium? Totalnie nie, a często to wręcz armata na muchę. Alternatywą może być Bot Pattern. To taki sposób na uporządkowanie kodu, który wygląda, jakbyście gadali do bota – czyli posługując się komendami.
Zestaw testowy
Weźmy na przykład zestaw bardzo prostych testów w Selenium, które sprawdzają poprawność działania koszyka w sklepie internetowym. Taki zestaw zawiera:
- Test sprawdzający, czy koszyk jest pusty, gdy nie dodano żadnych produktów;
- Test sprawdzający, czy po dodaniu jednego produktu do koszyka, w koszyku znajduje się tylko jeden produkt;
- Analogicznie – czy po dodaniu dwóch produktów do koszyka, w koszyku znajdują się dwa produkty;
- Test sprawdzający, czy zmiana liczby sztuk danego produktu w koszyku wpływa na wyświetlaną kwotę do zapłacenia;
- Test sprawdzający, czy aktualizacja ilości sztuk w koszyku do wartości ujemnej jest niemożliwa.
Wszystkie te testy zobaczycie poniżej:
POM vs Bot Pattern – przykłady
Bot Pattern polega na tworzeniu abstrakcji nad Selenium za pomocą komend, które są zorientowane na poszczególne akcje. Oznacza to, że zamiast bezpośrednio korzystać z Selenium, użyjecie zestawu komend, które są stworzone w sposób bardziej zrozumiały. Czyli przykładowo, zamiast tego:
w testach z Bot Pattern napiszecie to:
Inny przykład – zamiast tego:
można zrobić to:
Czyli jak widzicie, będziecie po prostu odwzorowywać poszczególne akcje ukrywając drivera i to, co się dzieje pod spodem na poziomie Selenium. Dzięki temu kod jest bardziej przejrzysty, a samo pisanie testów jest prostsze. Spójrzcie na przepisane testy:
Oraz na klasę ActionBot, która zawiera metody z akcjami:
Kiedy używać Bot Pattern
W zasadzie zawsze, gdy wydaje Wam się, że Page Object Model może być trochę przekombinowany. Można od razu zacząć od Bot Pattern i zobaczyć jak to wyjdzie w praktyce. Jest on tak prosty, że na tym rozwiązaniu możecie później zbudować sobie POM, jeżeli zajdzie taka potrzeba. Nie musicie pozbywać się waszego bota.
Bot Pattern jest również szybszy do ogarnięcia i zdecydowanie prostszy. Będzie też lepszy do prostych aplikacji, które nie mają wielu funkcjonalności ani podstron, które potencjalnie byłyby kandydatami do stania się Page Objectami.
Ponadto, jeżeli zaczynacie pisać pierwsze testy w Selenium, to łatwiej będzie zacząć właśnie od Bot Pattern niż od POMa. Zwłaszcza, jeśli zespół testerski jest „młody”, czyli gdy jeszcze nie do końca rozumie budowę testowanej aplikacji. Testerzy mogą nie mieć umiejętności pozwalających ocenić, czy POM się w danym przypadku sprawdzi, ale mogą zacząć już coś automatyzować, żeby np. odciążyć testerów manualnych. Przyspieszy to proces tworzenia i testowania oprogramowania.
Jeżeli natomiast testowana aplikacja jest mocno rozbudowana i robi, mówiąc kolokwialnie, wiele rzeczy na różne sposoby, to może się okazać, że Bot Pattern na długo nie wystarczy.
I to by było na tyle jeśli chodzi o Bot Pattern. Jeśli jednak macie ochotę na więcej, to dajcie znać czego potrzebujecie. Zasiądźcie wygodnie w fotelu, weźcie popcorn i poczekajcie, aż rozprawię się z testerskimi zagwostkami w kolejnych artykułach. 😈