Skip to content

automatyzacja testów

Praca z lokatorami w konsoli przeglądarki

Sporo osób, szczególnie podczas początków nauki automatyzacji ma problem z tym jak weryfikować poprawność XPath i CSS Selectors.

Pełna dokumentacja dla nich jest w linkach poniżej:

W tym artykule pokażę jak możemy bawić się lokatorami bezpośrednio w konsoli przeglądarki. Rozwiązanie jest o tyle fajne, że wymienione rozwiązania działają w każdej przeglądarce (nawet w IE11, serio).

XPath

Weryfikacja elementów

Dla ilustracji przykładów będziemy pracować na stronie: http://automationpractice.com/index.php

Interesuje nas link Women na stronie głównej sklepu. Skopiujmy z przeglądarki XPath do schowka (używamy funkcji inspect na przycisku Women na stronie, a następnie w HTML prawym przyciskiem rozwijamy menu na zaznaczonym tagu)

Sprawdźmy teraz na co wskazuje skopiowany XPath walidując go w konsoli komendą $x() która zwraca efekt wyszukiwania elementów przez XPath (ta metoda zwraca zawsze tablicę elementów, pamiętajmy o tym pisząc własne lokatory)

1
$x("/html/body/div/div[1]/header/div[3]/div/div/div[6]/ul/li[1]/a")

Oczywiście ten sam XPath możemy napisać sami analizując DOM (kopiowanie lokatorów z przeglądarki jest dobre do nauki i w zasadzie zupełnie nieprzydatne podczas pisania testów automatycznych w pracy). Spróbujmy zatem znaleźć go „lepiej”:

1
$x("//a[@title='Women']")

Lepsza weryfikacja elementów

Używanie w tym miejscu XPath relatywnego („//a[@atrybut=’wartosc’]”) dalej nie jest najlepszym pomysłem bo:

  • title może się łatwo zmienić (w przypadku zmiany języka sklepu)
  • możemy mieć kilka elementów w DOMie o tej samej nazwie, a metoda findElement() Selenium zwróci nam pierwszy znaleziony, pomimo że lokator może zwrócić tablicę elementów w przeglądarce
  • element jest wyszukiwany w całym DOMie („//” wskazuje na Xpath relatywny), a nam zależy na konkretnym linku w sekcji linków na górze strony

Jak zatem możemy to poprawić? WebDriver pozwala nam szukać elementów zarówno na stronie jak i zagnieżdżonych w uprzednio znalezionych elementach (sprawdźcie interfejsy klas WebElement i WebDriver jeżeli mi nie wierzycie).

Znajdźmy zatem jaki charakterystyczny element na stronie (poszukajmy unikalnego ID). Po przejściu troszeczkę wyżej nad nasz link „Women” widać kontener na linki. Możemy go wyszukać w konsoli przez

1
$x("//div[@id='block_top_menu']")

Wyszukajmy zatem elementów tylko zagnieżdżonych w środku tego diva komendą poniżej ($0 wskazuje na zaznaczony element w inspektorze). Zakładam teraz, że raz założona kategoria sklepu jest taka sama na różnych środowiskach (co pewnie jest błędnym założeniem) i id_category=3 prowadzi zawsze do kategorii Women.

1
$x(".//a[contains(@href,'id_category=3')]", $0)

Wyszukaliśmy właśnie elementu a, który w atrybucie href zawiera id_category=3 w środku elementu zaznaczonego w inspektorze (czyli div id=”block_top_menu”)


CSS Selectors

Walidacja w przeglądarce

Analogicznie do znalezionego elementu bezpośrednio z przeglądarki możemy skopiować CSS Selector

A następnie zweryfikować go w konsoli, używając komendy $$(„”)

1
$$(".sf-menu > li:nth-child(1) > a:nth-child(1)")

W przypadku CSS Selectors też działa wyszukiwanie w znalezionym elemencie, tym razem znajdźmy całą listę elementów o klasie „sf-with-ul”:

Błędne lokatory

Problemem lokatorów w testach automatycznych jest to, że to zwykłe stringi. I błędny lokator (lub błędna składnia lokatora) rzucą nam tym samym błędem Selenium (NoSuchElementException).

W przypadku pracy w konsoli z lokatorami, już konsola pokaże nam błąd i zaoszczędzimy czas, który musielibyśmy poświęcić na debugowanie kodu.

Źródła i ćwiczenia:

Automatyzacja desktopowych aplikacji Windows 10 – cześć #2

Czyli uruchamiamy z poziomu frameworka WinAppDriver i odpalamy aplikację Notepad++. Wszystkie aplikacje są darmowe (wymagają niestety płatnego Windowsa 10, lub darmowej wersji studenckiej). Nie testowałem podanych dalej rozwiązań na innych wersjach Windowsa niż 10.

Zaczniemy od kodu uruchamiającego WinAppDrivera (uprzednio zainstalowaliśmy go w domyślnej lokalizacji).

Read More →

Automatyzacja desktopowych aplikacji Windows 10 – cześć #1

W tym artykule przygotujemy sobie bazę do pisania testów w Gherkinie i utworzymy szkielet całego frameworka.

Jeżeli jesteś „początkujący” i jest to Twój pierwszy kontakt z C#/SpecFlow/Appium to polecam przeczytać najpierw wpis na blogu testuj.pl, w którym wszystko jest opisane krok po kroku od podstaw. Tutaj celowo pomijam te elementy, które są tam opisane wystarczająco dokładnie.

Krótki powód dla którego wybrałem taki a nie inny stack technologiczny: wszystko jest darmowe, do wszystkiego mamy zaplecze w postaci społeczności rozwijającej produkt, aplikacje na Windows 10 zazwyczaj są pisane w C# w Visual Studio (co pozwala część problemów rozwiązać wspólnie z developerami). Bo bez pomocy developerów, automatyzacja aplikacji na platformę UWP ma marne szanse powodzenia.

Read More →