Kontynuując serię wpisów księgarskich (pierwsza część tu: Ksiażki o testowaniu oprogramowania – po polsku i dla początkujących a druga tu: Książki o testowaniu oprogramowania – po polsku, część #2) nadal przyglądam się książkom o testowaniu. Oto książki o testach automatycznych, które udało mi się znaleźć. Są to pozycje o testach automatycznych ale nie o testach jednostkowych – niestety w księgarniach bywają one wrzucane do jednej kategorii, a niestety jest to sprawa oddzielna – według większości znanych mi praktyk (podkreślam: praktyk, nie teorii 😉 ), testy jednostkowe piszą programiści, a pozostałe testy – testerzy.
Archiwa tagu: testy automatyczne
Książki o testach jednostkowych
Kolejny rzut książek o testowaniu automatycznym, tym razem coś dedykowanego raczej dla programistów, czyli… Książki o testach jednostkowych (zwanych także unit testami) – po polsku.
Testy jednostkowe. Świat niezawodnych aplikacji
Wydawnictwo to http://helion.pl.
Autor: Osherove Roy
Liczba stron: 320
JUnit – testy jednostkowe. Kurs video. Automatyzacja procesu testowania w Javie
Tym razem kurs wideo, autorstwa Zofii Matusiewicz.
JUnit. Pragmatyczne testy jednostkowe w Javie
Autorzy to Andy Hunt i Dave Thomas. Wydawnictwo Helion.
Raptem 192 strony, nie jest to więc opasłe tomisko, które będzie tylko zalegało na półce.
TDD. Programowanie w Javie sterowane testami
Do zakupienia np. tu: http://helion.pl/
Viktor Farcic, Alex Garcia
Stron: 256
Języki skryptowe do automatyzacji testów
Początkujący adepci testowania automatycznego zastanawiają się czasem, jakie są języki skryptowe do automatyzacji testów?
W czym można automatyzować testy?
Z jednej strony można odpowiedzieć, że prawie we wszystkim. Większość języków oprogramowania nadaje się do automatyzacji testów, a to za sprawą wszechstronności bibliotek używanych do testów.
Np. Selenium, świetne do automatyzacji stron webowych, umożliwia pisanie testów interfejsowych w wielu językach, z czego najpopularniejsze to:
- C# (wraz z NUnit w roli test runnera),
- Java (tu do wyboru jUnit lub TestNG),
- JavaScript (jak to w świecie JS – masa frameworków: WebdriverJS, WebdriverIO, NightwatchJS),
- Ruby (RSpec, Test::Unit),
- Python (Robot Framework, unittest, pyunit, py.test),
- PHP (Behat, Mink).
Podobnie jest w innych narzędziach do automatyzacji, bazujących na driverze – np. Appium.
Języki skryptowe do automatyzacji kontra języki kompilowane
Najlepszym wyborem dla testera będą jednak języki skryptowe. Omijają typowe problemy języków kompilowanych, oferując mnóstwo już zaimplementowanych, typowych funkcji.
Przykład? Wczytanie i sparsowanie pliku CSV do listy w Pythonie zajmuje cztery linijki. CZTERY LINIJKI:
Narzędzia do automatyzacji aplikacji desktopowych
Jakich narzędzi można użyć do automatyzacji aplikacji desktopowych, działających w systemie Windows (Windows Forms, WPF)?
Na szczęście istnieje wiele rozwiązań, dzięki którym pisanie testów automatycznych może być całkiem skuteczne. Poniżej kilka propozycji. Większość z nich jest darmowa – poza licencją na Visual Studio (w przypadku pierwszej grupy, opartej o .NET Framework lub rozwiązań Microsoftu).
Zapraszam do lektury:
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/.
Dobre praktyki w automatycznych testach w Selenium:
- Podstawowa zasada – używanie aktywnego czekania (
WebDriverWait, wait.Until, ImplicitlyWait
itd.) zamiastThread.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
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 atrybutudisabled
. Element z takim atrybutem będzie „wyszarzony”.checked
– element jest zaznaczony. Dotyczy pól typuinput
– zarówno typuradio
jak icheckbox
.
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 }
Asert w NUnit
Jednym z bardziej elementarnych składników testów są asercje, umożliwiające sprawdzenie, czy spełnione są warunki testu.
W NUnicie dostępnych jest wiele różnych asercji. Najprostsza to:
Assert.AreEqual
To jednak nie wszystko. NUnit oferuje cały wachlarz asercji – warto spojrzeć w dokumentację [equalConstraint] i [assertions].
Bardzo fajną opcją jest na przykład sprawdzenie, czy kolekcja jest posortowana:
var notSorted = new List<decimal>(); notSorted.Add(12.3); notSorted.Add(5.5); notSorted.Add(100); Assert.That(notSorted, Is.Ordered);//Fail
Poza klasycznymi asercjami NUnit oferuje też np. StringAsert, CollectionAsert itd.
Testy automatyczne – odrobina teorii
Mój drugi artykuł dla serwisu PasjaOnline wprowadza czytelników w świat testowania automatycznego. Serdecznie zapraszam do lektury: czym są testy automatyczne http://pasjaonline.pl/testy-automatyczne/.