TestWatchman je v podstatě interceptor, který můžete zavěsit na události failed, finished, starting a succeeded. Ukažme si na následujícím příkladě, jak zareagovat na neúspěšný test a zjistit jméno třídy a název testu. Tento string používáme jako jméno screenshotu v našich selenium testech. Metoda failed se volá jak při assertationFailed tak při výjimce.

import static junit.framework.Assert.fail;

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.MethodRule;
import org.junit.rules.TestWatchman;
import org.junit.runners.model.FrameworkMethod;

public class MyTest {

	@Rule
	public MethodRule watchman = new TestWatchman() {
		@Override
		public void failed(Throwable e, FrameworkMethod method) {
			String methodName = MyTest.this.getClass().getSimpleName() + "." + method.getName();
			System.out.println(methodName + " has failed!");
		}
	};

	@Test
	public void testFailed() {
		fail();
	}

}

Pro představu. Máme za úkol pokrýt testy funkčnost založení uživatele. Máme dvě poměrně jednoduché obrazovky:

Seznam uživatelů:

Vytvoření nového uživatele:

Jeden test bude na pozitivní scénář založení uživatele. Další test bude na založení uživatele s existujícím uživatelským jménem. Potud je to dobré a vystačili bychom si i s naklikanými testy. Ale jak se začnou množit další scénáře vyžadující založeného uživatele, začínáme se dostávat do problémů. Editovat uživatele, smazat uživatele, zablokovat uživatele, založit požadavek s uživatelem s příslušnou rolí, atd. Původně jsme to řešili privátními metodami v rámci test třídy. To ale nestačí, pokud potřebuji např. založit uživatele v rámci jiného testu. Tak si začnu vytvářet různé helper třídy, ale v tu chvíli v tom začíná být trochu zmatek. Člověk neví, jestli daný kód napsat do helper třídy nebo přímo do testu. Nebyli jsme s tímto stavem spokojeni.

Page Objects návrhový vzor to krásně řeší. Zjednodušeně vytvářím dva druhy tříd. Testy a stránky (Page Object). Page obsahuje metody, které znamenají služby, jaké stránka nabízí z pohledu uživatele. Např. tlačítka, vyplnění formuláře, odkazy, atd. Další metody umožňují zjišťovat stav, v jakém se stránka nachází. Např. počet záznamů v tabulce, přítomnost chybové hlášky, atd. Všechny tyto metody jsou implementovány pomocí Selenium API.

Testy samotné pak naopak nepoužívají Selenium API vůbec. Pouze sestavují testovací scénář voláním sérií služeb na jednotlivých stránkách. A pak také obsahují veškeré asserty. Zjistí stav pomocí metody na stránce a ověří ho. Asserty nepatří do stránky a zase Selenium volání nepatří do testu. S těmito jednoduchými pravidly se dají vytvářet velmi přehledné a čitelné testy.

Tady je příklad na otestování funkce založení uživatele v Orinoco platformě.

Stránka odpovídající formuláři na založení uživatele:

@Page
public class CreateUserPage extends AbstractOrinocoPage {

    @Override
    public boolean isValidPage() {
        return selenium.isElementPresent("page_user__createUser__do");
    }

    public CreateUserPage fillForm(TestUser user) {
        selenium.type("username", user.getUserName());
        selenium.type("password", user.getPassword());
        selenium.type("confirmedPassword", user.getPassword());
        for (String userType : user.getUserTypes()) {
            selenium.addSelection("name=roles", "value=" + userType);
        }
        selenium.type("firstName", user.getFirstName());
        selenium.type("lastName", user.getSurname());
        selenium.type("email", user.getEmail());
        return this;
    }

    public UserListPage create() {
        clickAndWait("common_action_create_button");
        return navigateTo(UserListPage.class);
    }

}

Jsou tam implementovány dvě “služby”. Vyplnění formuláře a stisknutí tlačítka Create. Všimněte si, že zde se přímo používá Selenium API. Dobré bývá také pracovat s daty tak, že jsou zapouzdřené do objektů. Na jednom z projektů jsme dokonce použili přímo DTO objekty, protože už byly hotové a odpovídaly přesně formulářům. Chybí metoda pro Storno tlačítko, ale to nevadí. Doplní se, až bude potřeba pro nějaký scénář. Předek této třídy dává tušit, že bude obsahovat metody odpovídající hlavnímu menu a celému záhlaví.

Takto vypadá Page objekt pro seznam uživatelů:

@Page
public class UserListPage extends AbstractOrinocoPage {

    @Override
    public boolean isValidPage() {
        return selenium.isElementPresent("page_user__listUsers__do");
    }

    public CreateUserPage createUser() {
        clickAndWait("//a[@href='createUser.do']");
        return navigateTo(CreateUserPage.class);
    }

    public TableControl getUserTable() {
        return getTableControl();
    }

}

Je tu implementována jenom jedna metoda na přidání nového uživatele. Za zmínku určitě stojí navigace. Každá metoda, která něco dělá s aplikací, vrací objekt typu Page. Buď vrací novou stránku při přechodu nebo sebe sama, pokud browser zůstává na stejné stránce. Metoda getUserTable() jenom zjišťuje stav na stránce. TableControl je pomocný objekt na práci s tabulkami. Ani na jedné ze stránek není jediný assert. Ten přísluší Test třídě.

Test case pro správu uživatelů:

public class UserManagementTest extends AbstractOrinocoTest {

	private DashboardPage dashboardPage;

	@Before
	public void login() {
		dashboardPage = loginPage.login("habele", "a");
	}

	@Test
	public void createUser() {
		TestUser user = new TestUser("selAdmin", "selAdmin", Arrays.asList(TestUserType.ADMIN),
				"selAdmin", "selAdmin", "selAdmin@aspectworks.com", true);

		UserListPage userListPage = dashboardPage.openSettings().openUserManagement();
		CreateUserPage createUserPage = userListPage.createUser();
		createUserPage.fillForm(user).create();

		TableControl userTable = userListPage.getTableControl();
		TableRow row = userTable.getRow(user);
		assertNotNull(row);
		assertEquals(user.getUserName(), row.getCell(3));
	}

}

Test case má standardní průběh. Příprava testovacích dat, provedení testu a kontrola výsledku. Se stránkami se velmi dobře pracuje zřetězeně právě kvůli tomu, že metody zase vrací Page objekty. Test už vůbec nepracuje se Selenium API. Vše nechává uvnitř stránek.

Návrhový vzor Page Objects se velmi osvědčil. Je to přirozený návrh tříd podle uživatelského rozhraní. Testy se velmi snadno tvoří a čtou a znovupoužitelnost je velmi dobrá. Ze stránek se navíc dají tvořit další objekty vyšší úrovně zapouzdřující celé moduly. Lze pak třeba založit uživatele jedním řádkem a pokračovat ve psaní skriptu toho, co zrovna testujeme.

V tomto článku nebylo zmíněno ještě několik součástí, které jsou vidět ze zdrojových kódů. Jak jsou stránky a testy konfigurovány a jak jsou tvořeny instance? Jak probíhá navigace mezi stránkami? Jak ověřit, že se browser nachází na stránce, na které je volána metoda služby? Jak funguje TableControl? O tom zas někdy příště.

Obvykle každý ví, že rodná čísla se tvoří od roku 1954 ve tvaru yymmdd/xxxx a ta starší mají tvar yymmdd/xxx. Pokud je to žena, přičte se k měsíci 50. Také si každý myslí, že by mělo být rodné číslo dělitelné jedenáci. Ale zde je právě kámen úrazu. Vše je trochu jinak.

Poslední desátá číslice přidávaná od roku 1954 je kontrolní a tvoří se tak, že se vydělí devitimístné číslo jedenácti a zbytek po dělení se použije jako desátá kontrolní číslice. Tím je výsledné desetimístné číslo dělitelné jedenácti. Tedy v případě, že zbytek po dělení nebyl 10. V takovém případě je kontrolní číslice rovna 0, ale tím pádem není celé rodné číslo dělitelné jedenácti. Do roku 1985 bylo přiděleno cca 1000 rodných čísel, která nejsou dělitelná 11. Není vyloučeno, že se v minimálním počtu vyskytly i po tomto roce.

Navíc od roku 2004 je zavedena možnost v případě, že jsou v nějaký den vyčerpána všechna platná čtyřčíslí, použít alternativní rodné číslo, u kterého mají muži k číslu měsíce přičteno 20 a ženy 70. A i rodná čísla před rokem 1954 mohou mít čtyřčíslí, pokud se jednalo o dodatečně přidělená rodná čísla (např. při získání občanství).

Více informací třeba na Wikipedii nebo na tomto blogu.

Většina aplikací se spokojí s ověřením dělitelnosti jedenácti. Ale to je evidentně špatně. Ještěže nemám tu smůlu a nemám nestandardní rodné číslo

Napsal jsem pro účely Selenium testů generátor rodných čísel s několika možnostmi, jak číslo generovat:

• pro konkrétní datum a pohlaví
• pro věkové rozpětí – vhodné třeba pro generování mladistvých
• oficiální rodné číslo – dle výše popsaných pravidel
• běžné rodné číslo – takové, které čeká většina aplikací – dělitelnost 11, standarní tvary
• speciální rodné číslo – takové, které není běžné – vhodné pro test validace

Ukázka použití generátoru:

// generates random personal number from 1900 till today
String personalNumber = RcGenerator.generateRc();

// men between 18 and 30
personalNumber = RcGenerator.generateRcForAge(18, 30, Gender.MALE);

// common personal number modulo 11 == 0 which passes most validators
personalNumber = RcGenerator.generateRc(RcType.COMMON);

Přiložené třídy můžete volně použít. Budu rád, když najdete chyby nebo generátor vylepšíte, rozšíříte funkčnost a s kódem se zase podělíte.

RcGenerator.zip

Pozor na pořadí anotací! Řešení popsané ve zmiňovaném článku volá nejprve metodu anotovanou @After a poté teprve @AfterFailure. To samo o sobě není problém, pokud stejně jako my v metodě anotované @After nevoláte metodu Selenium#stop(), která zavírá prohlížeč. To pak vám je získaný snímek obrazovky k ničemu. Rešení je jednoduché, stačí v runneru jen prohodit volání metod v metodě #withAfters(FrameworkMethod, Object, Statement).

@Override
protected Statement withAfters(FrameworkMethod method, Object target, Statement statement) {
      statement = withAfterFailures(method, target, statement);
      return super.withAfters(method, target, statement);
}

Věřím, že vám snímky v případě selhání Selenium testů ušetří čas při opravování bugů.

Edit
JUnit od verze 4.7 má svoje řešení jménem TestWatchman.

V AspectWorks jsme fanoušky kontinuální integrace. Píšeme unit testy, snažíme se o dobré pokrytí kódu a s každým commitem do SVN spouštíme integrační build. Aktuálně používáme TeamCity jako server na kontinuální integraci. O selhaných buildech nás doteď informovaly emaily, Jabber, vyskakovací okýnka v Eclipse, atd. Nuda!

Teď jsme si ale pořídili tu správnou vychytávku na notifikaci o buildech: Tux plugin do TeamCity.

Jak to funguje? Jednoduše – když někdo rozbije build, tučňák Tux začne křičet, který build selhal.

Pokud nemáte zrovna TeamCity, nevadí – Tux API je docela jednoduché, takže si můžete celkem rychle udělat plugin pro vlastní build server.

TuxAPI tux = new TuxAPI(ipAdress, port);
tux.server.autoConnect(TuxAPIConst.CLIENT_LEVEL_RESTRICTED, "login", "password");
tux.tts.speak("Text to speach");

Vřele doporučuju nějakou takovou blbinu zavést.

Představte si například situaci, kdy v properties vaší aplikace potřebujete nastavit, zda se Spring Security bude autentizovat vůči databázi nebo vůči LDAPu.

Jak na to?

Nejdříve nastavte v properties takovýto klíč:
myApplication.authentication.provider=ldap

Target beana libovolného jména definovaného v properties bude díky BeanReferenceFactoryBean dostupná vždy pod jediným a předem známým id.

<bean id="authenticationProvider" class="org.springframework.beans.factory.config.BeanReferenceFactoryBean">
	<property name="targetBeanName">
		<value>${myApplication.authentication.provider}AuthenticationProvider</value>
      </property>
</bean>

Do authentication-manageru nainjektujeme beanu authenticationProvider, jejíž target beana je zvolena právě na základě konfigurace v properties.

<sec:authentication-manager>
	<sec:authentication-provider ref="authenticationProvider"/>
</sec:authentication-manager>

Pro úplnost ještě uvádím nástin konfigurace Spring Security vůči databázi a LDAP.

<bean id="dbAuthenticationProvider" class="org.springframework.security.authentication.dao.DaoAuthenticationProvider" lazy-init="true">
	<property name="userDetailsService" ref="userDetailsService" />
</bean>

Lazy-init je nastaveno na true, protože pokud si vyberete autentizaci vůči databázi, tak nebudete konfigurovat LDAP a naopak. S nevalidním nastavením by vám pak vůbec nenaběhl aplikační kontext.

<bean id="ldapAuthenticationProvider" class="org.springframework.security.ldap.authentication.LdapAuthenticationProvider" lazy-init="true">
	<!-- configuration of LDAP -->
</bean>

Místo nového buildu teď stačí pro změnu konfigurace jen upravit nastavení v properties a restartovat aplikační server.

Pochopitelně jedním základním sporem je volba architektury. Zda jít cestou tzv. standardů a zvolit tak architekturu např. JSF, EJB3, JPA a nasadit aplikaci na plnohodnotný JEE aplikační server a nebo jít cestou POJO objektů, Spring kontejneru, Hibernate, AOP zajištujícího middleware služby a celé to nasadit třeba na Tomcat. Až mě překvapuje, kolik Java vývojářů vnímá tuto volbu architektury jako otázku “buď a nebo”. Je skutečně nutné se rozhodnout pro jedno, nebo je Spring skutečně jen framework pro zjednodušení práce s JEE aplikacemi?

Dalším a neméně významným třecím místem mezi Springem a JBossem je podle mě konkurence obou komunit. Spring už přece dávno není jen Spring Framework. Je to rychle rostoucí firma, nabízející celou řadu produktů, podobných těm od JBossu. Dokonce takový Spring dm Server je dnes vážný konkurent na poli aplikačních serverů. SpringSource nabízí komerční podporu, nástroje, školení, atd. Na druhé straně JBoss již také není jen server. JBoss Seam je plnohodnotný aplikační framework. Zde už by mohlo být podstatné architektonické rozhodnutí: JBoss Seam nebo Spring Framework?

Tímto krátkým úvodem vás zvu na druhé setkání skupiny JBoss User Group, které se bude konat 26.11.2009 od 9 hodin. Na začátku rozvedu výše nastíněná témata JBoss versus Spring a následně bude probíhat diskuze, behěm níž si vyměníme názory a zkušenosti z projektů. Těším se na vaší účast.

Update: Ve čtvrtek 26.11.2009 proběhlo setkání skupiny JBoss User Group na téma JBoss versus Spring. Informace o průběhu akce najdete ve zprávě Druhé setkání JBug ČR. Můžete si také stáhnout hlasový záznam [mp3, 13 MB] – omluvte prosím sníženou kvalitu záznamu.

Tyto scénáře testů nazýváme „testovanými scénáři“, anglicky test case, zkratkou TC. Co je to TC? Co by měl obsahovat? TC je soubor vstupů, kroků i podmínek a očekávaných výstupů. Ale kde ho vezmeme?

Každá analýza vyvíjeného systému by měla obsahovat případy užití (use cases), dále UC. Tyto scénáře užití lze s výhodou použít pro vytvoření seznamu TC. Jak na to? Ukážeme si na následujícím příkladu.

Nyní máme zpracovaný zcela jednoduchý UC, kde máme základní průchod aplikací. Bohužel svět není jednoduchý a ani náš příklad nemůže být takto jednoduchý. Je zapotřebí se zamyslet a definovat další toky, kterými může tento scénář být přerušen, či pokračovat zcela jinou cestu. Jedná se o tzv. Alternate flows.

Nyní si sepíšeme do tabulky pod sebe všechny možné scénáře, a pojmenujeme si je. Pojmenování volte rozumně, neboť by se mělo používat skrze celé testování.

Teď již máme identifikovány hlavní scénáře, které budeme potřebovat otestovat. Pro vlastní testování však toto ještě nestačí. Musíme definovat vstupy a očekávané výstupy jednotlivých TC. Vstupy lze identifikovat dle rozhodovacích bloků v UC. Každé alternative flow by mělo být způsobeno nějakou příčinou, vstupem. V našem případě máme situaci poněkud zjednodušenou. V reálných systémech jsou i desítky vstupů. Zde lze s výhodou použít excel, či vhodný TC management nástroj.

V našem případě dochází k startu alternate flow 3 v scénáři č.4: Datum splatnosti v minulosti.
Je tedy evidentní, že v tomto scénáři se rozhodne o provedení alternativního scénáře v bodě 6. Tudíž je zapotřebí zadat číslo faktury, částku a datum splatnosti. Číslo faktury a částka je validní a datum splatnosti je neplatné (Invalid). Další vstupy jsou již pro tento scénář irelevantní a v tabulce se neobjeví.

Nyní vyplňme tabulku. „V“ představuje potřebný validní vstup a „I“ invalidní vstup. Pokud na vstupech nezáleží nebo jsou irelevantní, zanechte příslušné buňku tabulky prázdnou. Názvy jednotlivých TC volíme ve sloupci TC ID# tak, aby odpovídaly testovanému scénáři. V našem případě jde o evidenci faktury, zvolil jsem tedy zkratku IE (Invoice Evidence). V případě velkých systémů nám toto pojmenování pomůže v orientaci.

Nyní máme tabulku validních a nevalidních vstupů. Víme, na kterých vstupech záleží úspěšnost dané operace. Připravíme si testovací prostředí tak, abychom mohli splnit tyto scénáře. Dost často mají UC tzv. preconditions. Tyto precondititons například říkají, že uživatel, který chce založit jiného uživatele, musí mít administrátorská práva. Musíte tedy do systému před začátkem testovaní založit uživatele s administrátorskými právy.
Na základě takto připraveného testovacího prostředí jste již schopni definovat konkrétní tabulku s konkrétními vstupy.
V našem případě vypadá například takto. Pokud používáte excel, doplňte si tabulku o sloupce precondition a postconditions. Tam definujte, co je zapotřebí udělat před spuštěním testu a zároveň co má tester udělat po ukončení testu. (například po sobě v aplikaci uklidit).

Dost často na svých školeních se setkávám s názorem, že tento postup je příliš přebyrokratizovaný a prý zdržuje. Praxe ovšem ukazuje, že problémem není vyplnění tabulky, ale neochota některých (test) analytiků se dopředu zamyslet a definovat tyto scénáře a vstupy. Pokud se ovšem nechcete smířit s intuitivním testováním a postoupit například až k objektivnímu měření kvality, zavedení podobných pravidel vás nejspíše nemine.

Pozorný čtenář teď zareaguje: Vždyť v těch TC nemám přeci kroky, jak mám postupovat? Tehdy ale nehledáme artefakt TC ale Test Script. Čili postup, kterým bude tester postupovat při ověřování konkrétního testovaného případu. Test Scripty psát je časově náročné a mnohdy se musí s měnící aplikací znovu přepisovat. Proč je tedy píšeme?

Rozdíl mezi TC a Test Script je v době jejich vzniku a v tom, kdo tyto artefakty vytváří. Zatímco k definici TC dochází na začátku projektu a provádí je test analytik (dosti často i analytik projektu), tak Test Scripty si píší sami testeři.

Oblast okolo názvů, tvorby TC a organizace práce je natolik rozsáhlá, že by vydala na několik článků. Pokud máme menší projekty a sdílené role, potřebujeme relativně malý aparát. Pokud ovšem projekt přerůstá určitou hranici, je zapotřebí zvolit adekvátní metody přístupu k testování.

Předchozí díl: Úvod seriálu