Selenide automatyzacja testów – tworzymy kolejne testy
Czas wrócić do naszego projektu automatyzacji testów w Selenide. Dziś w drugiej części dopiszemy kolejne testy. Przypominam, że cały projekt i kod znajdziesz w repozytorium: Projekt Selenide.
Dziś naszym zadaniem będzie sprawdzić, czy na stronie miasta Krakowa w jednym z kontenerów znajduje się 16 artykułów. Za pomocą Selenide taki test zajmie nam dosłownie kilka linijek kodu.
Jako że są to nasze pierwsze testy, dodamy je jeszcze w klasie z poprzednim testem. Od kolejnego wpisu zaczniemy już większy projekt automatyzacji na nowej stronie. Ważne, żebyśmy zrozumieli w pierwszych dwóch wpisach jak łatwe i szybkie jest tworzenie testów.
Nasz drugi test z Selenide
Tak samo jak poprzednim razem zaczynami od adnotacji Test. Następnie nazywamy nasz test w tym wypadku będzie to nazwa testSizeItemsInArticleContainer. Na temat konwencji nazewniczych testów poświęcimy sobie jeszcze osobny wpis.
Ponownie jak w przypadku ostatniego testu otwieramy przeglądarkę. Tym razem zrobimy to w inny sposób, zamiast przechodzić przez stronę, wyszukiwarki wejdziemy bezpośrednio na URL.
Następnie po raz pierwszy użyjemy podwójnego znaku dolara. Jaka jest różnica w Selenide pomiędzy $ a $$?
Bardzo prosto to wytłumaczyć, znak pojedynczego dolara ($) stosujemy mamy do wskazania pojedynczy jeden element. Selenide zwraca nam wtedy obiekt klasy SelenideElement, który jest reprezentowany przez przykładowo css selektor.
W przypadku użycia podwójnego znaku dolara ($$) zostaje nam zwrócony obiekt ElementsCollection, który ma za zadanie reprezentować zbiór wszystkich elementów, jakie zostaną znalezione przez dany selektor.
Następnie sprawdzamy asercją z Selenide czy takich elementów jest 16, jeśli właśnie tyle elementów zostanie znalezionych test kończy się pomyślnie
Trzeci test w Selenide
Nasz trzeci test ma za zadanie sprawdzić, czy tytuł strony jest zgodny z tym czego oczekujemy. Ten test jesteśmy w stanie napisać jeszcze szybszej niż poprzedni. Wystarczy, że otworzymy ponownie naszą przeglądarkę.
Następnym krokiem jest napisanie asercji, sprawdza ona czy nasza wartość aktualna wartość jest równa z oczekiwaną.
Do pobrania aktualnej wartości używamy tutaj Selenide.title() za jego pomocą pobieramy aktualny tytuł strony, na której się znajdujemy, po przecinku zostaje nam podanie oczekiwanego rezultatu.
Co dalej?
Mam nadzieje, że udało Ci się również napisać te testy i wypróbować. Warto również poeksperymentować i spróbować, napisać takie testy dla wybranej przez siebie strony. : )
Zapewne pojawiają się w Twojej głowie pytania, czy tak się powinno pisać testy, czy powinny być one w jednej klasie, czy nazwy testów są prawidłowe. To wszystko będziemy przepracowywać w kolejnych wpisach gdzie będziemy tworzyć kolejne testy w Selenide.
Przypominam, że całość kodu możesz znaleźć na GitHubie Project Quality.
Zapraszam Cię również do zapisania się na newsletter, abyś nie przegapił kolejnych wpisów poświęconych automatyzacji testów.
Dział automatyzacji testów na blogu: klik
Hej, doświadczenie nauczyło mnie, że pisanie selektorów w ten sposób div>a>h4 jest dość kruche. Wystarczy że niedobry dev zmieni h4 na h3 albo doda kolejnego diva i test się sypie. W cypressie rzeczy szuka się po data tagach jeśli jest taka opcja lub w ten sam sposób w jaki robi to user – z wykorzystaniem tekstu, labelel, placeholderów. Czy w selenide też jest taka opcja?