Archiwa tagu: selenium

Page Object Pattern + Fluent Interface

Page Object Pattern jest jednym z częściej używanych wzorców w testach interfejsowych. Nie bez powodu – pozwala świetnie odzwierciedlić architekturę aplikacji w testach, zapobiega także niepotrzebnemu powtarzaniu kodu, jeżeli pewne struktury powtarzają się w wielu miejscach aplikacji (na przykład wspólne dla każdej podstrony menu).

Jeden Page Object powinien odwzorowywać jeden logiczny fragment aplikacji. Posługując się przytoczonym wyżej przykładem menu, klasa „Menu” będzie zawierać wszystkie pozycje w menu (a jeśli ma ono strukturę hierarchiczną, także i zagnieżdżone, kolejne Page Objecty).

Każda metoda w klasie udostępnia oferowane przez obiekt usługi (np. rozwinięcie i zwinięcie podmenu, wybór pozycji itd.).

W tym wzorcu metoda zawsze zwraca Page Object (z czego korzysta kolejny wzorzec: Fluent Interface). Dzięki temu w testach można stworzyć bardzo elegancko wyglądającą ścieżkę wędrówki pomiędzy podstronami.

Z pozoru te same akcje mogą zwracać różne wyniki, np. dwie metody:


public AdminPage LoginWithCorrectCredentials(string userName, string password);

public ErrorPage LoginWithIncorrectCredentials(string userName, string password);

Asercje wykonywane są w testach, nie w klasach Page Objectowych.

Sterownik (WebDriver) może być przekazywany w konstruktorze Page Object.

Dobre praktyki w testach Selenium

Selenium jest narzędziem pozwalającym pisać testy automatyczne aplikacji webowych. Dzięki szerokiej gamie możliwości, sporej społeczności i kompatybilności od lat cieszy się dużą popularnością. Na oficjalnej stronie można znaleźć wiele materiałów: https://www.seleniumhq.org/.

Kawa i Selenium. Czemu nie?

Foto: moje, 2016

Dobre praktyki w automatycznych testach w Selenium:

  • Podstawowa zasada – używanie aktywnego czekania (WebDriverWait, wait.Until, ImplicitlyWait itd.) zamiast Thread.Sleep, który spowalnia testy, nie dając jednocześnie gwarancji, że zastosowana przerwa jest odpowiednio długa (jest wiele artykułów na ten temat w sieci).
  • Wyszukiwanie elementów na stronie za pomocą selektorów CSS (By.CssSelector) lub identyfikatorów ID lub name (By.Id, By.Name) – taka metoda jest o niebo szybsza niż wyszukiwanie przez XPATH.
  • Używanie wzorca Page Object.

Dobre praktyki w testach automatycznych

Czytaj dalej

How to check if element is invisible in Ruby Selenium client

How to check if element is invisible in Ruby Selenium client? In Java or C# answer is easy. There is a mechanism called ExpectedCondition, which has got ready for use method: ExpectedConditions.invisibilityOfElementLocated. Example:

driverWait.until(ExpectedConditions.invisibilityOfElementLocated(element));

Unfortunatelly, Ruby client hasn’t got anything like this. Quick workaround – try to find element. When element is not displayed, catch exception and return false:

def check_if_not_exist(locator)
  begin
    wait = Selenium::WebDriver::Wait.new :timeout => 10
    wait.until { @driver.find_element(:name, 'elementName').displayed? }
  rescue
    false
  end
end

Not very elegant and quick, but works.

 

Sprawdzanie czy checkbox jest zaznaczony w Selenium (C#)

Każdy z obiektów znalezionych przez Selenium jest standardowym obiektem typu WebElement. Udostępnia on następujące metody (których wartość zwracana jest typu bool):

  • displayed – element jest widoczny.
  • enabled – element jest aktywny – można go kliknąć, wpisać mu wartość itd. W praktyce każdy element dostępny na stronie ma stan enabled, gdyż jest to stan domyślny. „Wyłączyć” można go jedynie poprzez celowe dodanie do HTML atrybutu disabled. Element z takim atrybutem będzie „wyszarzony”.
  • checked – element jest zaznaczony. Dotyczy pól typu input – zarówno typu radio jak i checkbox.

Kawałek kodu HTML-owego, do którego zastosuję Selenium:


<html>
<body>
<form>
<input type="checkbox" />
</form>
</body>
</html>

Oraz fragment kodu C# z wykorzystaniem Selenium:


[Test]
public void CheckboxIsChecked()
{
  driver.url="file:///C:/DOCUMENTS/test.html";
  var el = driver.FindElement(By.TagName("input"));
  var before = el.Selected;//false
  el.Click();
  var after = el.Selected;//true
}

Selenium: Exception „Compound class names are not supported”

Today something about one of exceptions that can occure in Selenium PageFactory.

IllegalLocatorException was unhadled by user code.
An exception of type „OpenQA.Selenium.IllegalLocatorException” occured in WebDriver.dll but was not handled in user code.
Additional information: Compound class names are not supported. Consider searching for one class name and filtering the results.

In my case, this exception was thrown in line:

PageFactory.InitElements(webDriver, pageElement);

This is probably a bug in Selenium. Solution is easy: just do not use:

[FindsBy(How=How.ClassName, Using="name_of_class"]

Instead of ClassName, try to use Css Selectors:

[FindsBy(How=How.CssSelector, Using=".name_of_class"]

Remember about a dot!

Lista narzędzi testerskich

Jeżeli kiedykolwiek zastanawiałeś się, jakiego narzędzia lub podejścia użyć w celach testowania różnego rodzaju aplikacji, może natknąłeś się na listę narzędzi testowych sporządzoną przez The Minstry of Testing (powiedzmy, taki odpowiednik polskich Testerzy.pl).

Foto: moje, 2007

Lista jest naprawdę imponująca – zawiera wiele narzędzi, pogrupowanych wg celu, np. testowanie aplikacji www, desktopowych, zarządzanie testami itd.

Link: http://www.ministryoftesting.com/resources/software-testing-tools/

Niektóre z narzędzi:

Czytaj dalej