Před nějakou dobou jsme psali o vlastní anotaci @AfterFailure v JUnit testech. Naší motivací byly screenshoty neúspěšných selenium testů. JUnit od verze 4.7 má svoje řešení jménem TestWatchman.
Blog
Selenium a návrhový vzor Page Objects
Selenium používáme úspěšně už několik posledních projektů. Vždycky byly automatizované testy přínosem pro kvalitu aplikace a ušetřily obrovské množství rutinní práce testerům. Představa, že lze vytvořit Selenium test tak, že se “nakliká”, a pak ho už budeme jen dokola pouštět, vezme hodně rychle za své. Je jasné, že některé části testů bude potřeba použít několikrát a že DRY princip platí i zde. Nakonec stejně nezbývá nic než použít skriptovací nebo programovací jazyk a Selenium testy udržovat jako každý jiný kód. Jak ale testy navrhovat a strukturovat? S tím jsme se nějakou dobu potýkali. Až jsem objevil návrhový vzor Page Objects.
Generátor rodných čísel
V poslední době se věnuji automatizovaným Selenium testům jednoho obchodního systému. Při vkládání osob do systému je nutné zadat rodné číslo a systém provádí jeho validaci a sleduje, jestli je v systému unikátní. Abych mohl automatizovat funkčnost zakládání osob, tak jsem se rozhodl, že vytvořím generátor rodných čísel. Není vše ale tak jednoduché, jak by se mohlo zdát.
JUnit anotace @AfterFailure
Na automatické testování GUI našeho produktu Orinoco používáme framework Selenium. Pro identifikaci a opravu chyby je často klíčové vědět, co uživatel(respektive selenium test) v okamžiku chyby viděl. Selenium umí uložit snímek obrazovky, ale jak definovat okamžik, kdy ho má vytvořit? Nechtěli jsme mít přesně definované, které obrazovky má pokaždé ukládat. Naopak jsme chtěli snímek jen v případě, když Selenium test selže. A k tomu právě lze využít vlastní anotaci @AfterFailure.
Unit testy nad in-memory databází
Použití in-memory databází pro testování je poněkud kontroverzní téma, ale nedělejte rychlé soudy – Tomáš Piňos na svém blogu naznačuje, za jakých okolností má testování za pomoci in-memory databáze svoje opodstatnění. Nenechte si ujít zajímavý článek “Unit testy nad in-memory databází“.
Rozbiješ build, seřve tě Tux!
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.
Spring: podmíněná konfigurace
Při vývoji aplikací ve Springu jste jistě narazili na problém nasazení do různých prostředí. Pravděpodobně jste to řešili vytvořením samostatných buildů. Ovšem ne vždy je to potřeba. Proč nenechat konfiguraci na adminovi? Existuje jednoduché a elegantní řešení jménem BeanReferenceFactoryBean.
Verzování datového modelu a LiquiBase
Liquibase je populární nástroj pro správu datového modelu. O jeho použití, i o různých činnostech, týkajících se správy datového modelu, sepsal náš kolega Tomáš Piňos pěkný článek – přečtěte si ho!
JBoss versus Spring
Ještě zhruba před rokem jsem si myslel, že JBoss a Spring nejdou v ničem proti sobě. JBoss je převážně aplikační server a Spring je framework na snadný vývoj lehčích JEE aplikací. Není přeci problém postavit webovou aplikaci na Spring frameworku a nasadit ji na JBoss server. Dokonce jsme to se svými projekty dělali a děláme i nadále. K hlubšímu zamyšlení na toto téma mě přivedla až jedna ostřejší diskuze během JBoss školení. O co jde?
Testujeme s rozumem (2.) – Jak z UC získat TC
Při přípravě na testování projektu je zapotřebí vytvořit scénáře (postupy), které budou testeři procházet při testování. Scénáře by v optimálním případě měly pokrývat případy užití, pro které je aplikace vyvíjena. Máme-li rozumně zpracovanou analýzu, může být získání těchto scénářů relativně snadné.