Po 3 letech dělám větší refaktoring na našem direct mailingovém modulu a jako první jsem se rozhodl povýšit verze knihoven a zrefaktorovat JUnit testy, které jsou tam ještě psané ve stylu JDK 1.4.
V souvislosti s tím jsem samozřejmě přepracoval formu testů z dědičné hierarchie na anotace, které byly představeny poprvé ve Spring 3.X (pokud se nepletu). A tu jsem zjistil, že mám drobný problém - v původní verzi mého kódu jsem využíval dynamické kompozice Springového kontextu k tomu, abych stejné integrační testy pustil proti různým implementacím úložišť dat (paměť, MySQL databáze, Oracle databáze .
Na tento poklad narazil kolega Jakub Liška, když si sám chtěl napsat něco podobného. Pokud používáte pro automatické testy podporu Springu a na vytváření mocků Mockito, máte řadu možností jak vytvářet mock objekty. Jednu z nich, která se mi zdála poměrně jednoduchá jsem popisoval v dřívějším článku Jak se zbavit nepříjemných závislostí v testech, nicméně tento přístup dotáhl Jakub Janczak o kus dál (jo na světě jsou milóny lidí chytřejších jak já :) ).
Many of complex applications put on top of their complexity access control logic for securing data and to limit access to certain functions. No matter if you have fully configurable ACL settings based on rights or role based access you'd probably want to test this part of application too. In order to have proper test coverage you should make it easy for you and your colleagues to test this. I have no doubts that if you ever needed to test this you already have some kind of such test support, but this article describes what kind of it I've created for myself.
Dnešní příspěvek bude velmi krátký. Je dost pravděpodobné, že podobné řešení už dávno máte ve svých tetovacích utilitkách, ale mě tato kombinace napadla relativně nedávno a jsem nadšený z toho, o jak elegantní řešení se pro testy jedná.
V některých testech potřebuji vytvořit část Spring aplikačního kontextu, jehož některé beany mají závislost na nějaké další beaně, kterou je pro mne obtížné do testu zahrnout. Buď z důvodu, že její samotné vytvoření s vyžaduje další komplexní infrastrukturu okolo ní nebo třeba proto, že její zařazení do testovacího kontextu způsobuje při běhu testu vedlejší efekty (např.
O autorovi: Jetyho blog | LinkedIn
Pavel Jetenský se věnuje Java/J2EE vývoji již od roku 2003, z toho několik let v Irsku. Zajímají ho techniky automatického testování. V současné době pracuje jako metodický vedoucí Java/J2EE v Deltax Systems a.s.
Občas při tvorbě automatických testů potřebujeme otestovat funkcionalitu, která stahuje nějaká data z Internetu. V mém případě to byla funkce na stahování seznamu zneplatněných certifikátů (CRL). Původně jsem měl automatický test napsaný tak, že se seznam skutečně stahoval.
V předchozím článku jsme si ukázali vylepšení iBatisu v souvislosti s XML deklaracemi. Tento navazující článek rozebírá novinky v oblasti Java API. Základem pro toto rozšíření se staly vlastnosti dostupné od verze Javy 1.5 - tedy generiky a anotace. Jednou z velkých kritik původního iBatisu bylo množství XML, které bylo nutné psát. Našlo se mnoho lidí, kterým tento přístup vadil a kteří by spíše uvítali mít vše na jednom místě v kódu.
O autorovi: Jetyho blog | LinkedIn
Pavel Jetenský se věnuje Java/J2EE vývoji již od roku 2003, z toho několik let v Irsku. Zajímají ho techniky automatického testování. V současné době pracuje jako metodický vedoucí Java/J2EE v Deltax Systems a.s.
Školení Selenium testování - základy je určeno pro začátečníky a seznamuje s prvními kroky s nástrojem pro automatizované testování webových aplikací v prohlížeči.
Popisuje jednotlivé příkazy frameworku, různé typy selektorů a způsoby spouštění testů.
Předevčírem se v mé RSS síti zachytila zajímavá zpráva, která dobře zapadá do katalogu řešení pro automatické testování. Jedná se o MockFtpServer, který se velmi podobá přístupu SubEtha SMTP Serveru, se kterým mám velmi pozitivní zkušenosti.
Princip je skutečně analogický zmiňovanému SubEtha SMTP Serveru, se kterým lze jednoduše ověřovat správné rozesílání emailů. Jednoduše nakonfigurujeme "virtuální" FTP server a nastartujeme jej na konkrétním portu. V testech pak můžeme ověřovat kód, který komunikuje s FTP serverem, aniž bychom museli vytvářet vlastní stub nebo mock objekty:
V polovině listopadu jsem měl na Univerzitě Hradec Králové přednášku o automatickém testování v Javě, ve které jsem zabrousil už trošku do větší hloubky než v té, která proběhla na jaře tohoto roku. Přestože jsem především závěr přednášky nemohl probrat do takových podrobností, jak bych rád, doufám, že se mi většinu nasbíraných zkušeností nějakým způsobem podařilo předat. Pokud vás tedy opakovaně trápí některé problémy při psaní unit a integračních testů, možná při poslechu zjistíte, že i já jsem řešil podobný problém a můžu vám nabídnout nějaký tip co s daným problémem udělat, popř.
Díky mému špatnému odhadu, kolik je možné probrat za hodinu a půl jsem se na minulé přednášce nestihnul dotknout žádného z pokročilejších témat souvisejících s automatickým testováním, se kterými se při douhodobém vývoji s použitím testů zcela jistě setkáte. Proto jsem se s Tomášem Kozlem z Univerzity Hradec Králové dohodl na druhé přednášce, která by se věnovala už jen pouze těmto záludnějším věcem a také rozkryla podporu pro testování ve Spring Frameworku.
O autorovi: Jetyho blog | LinkedIn
Pavel Jetenský se věnuje Java/J2EE vývoji již od roku 2003, z toho několik let v Irsku. Zajímají ho techniky automatického testování. V současné době pracuje jako metodický vedoucí Java/J2EE v Deltax Systems a.s.
Na Java Open Space jsem měl na téma Selenium lightning talk. Honza ho nahrál jako podcast a zveřejnil v předchozím článku, ale bohužel je v nahrávce hodně šumu.
Naštěstí ale ještě existuje screencast z původní verze školení Selenium testování GUI, které jsem prezentoval letos na jaře pro kolegy z mojí firmy.
Nice thing about Aspect Oriented Programming is that you can easily add piece of logic to several (possibly other way not connected) parts of your application. You'll only write an Advice (piece of code that should be weaved into original code and executed at exactly specified point of time) and define Pointcut (an expression defining which classes and methods shall be advised). Please, keep in mind, that above description is somewhat simplyfying and that AOP could be much broader than this.
Na dovolené se mi podařilo vyšetřit čas na sestříhání záznamu z přednášky Automatické testování v praxi, která se konala dne 21.4.2008 na Univerzitě Hradec Králové. Na přednášce se sešlo přes 30 posluchačů převážně z řad studentů univerzity. Přesto že jsem původně anoncoval, že se pokusím zabrousit i do pokročilejších témat, jako jsou testovací patterny a antipatterny, nástroje apod. musel jsem svůj záměr přehodnotit. V takovém případě bych se s přednášením dostal na dobré tři hodiny, přičemž na přednášku bylo vyhrazeno pouze minut devadesát.
Po delší době jsem měl zase čas podívat se na zoubek v mém TODO listu. Tentokrát jsem si vzal na paškál poměrně malou knihovnu s názvem Joda Time. Cílem této knihovny je reimplementace Java API pro práci s datumy a časem. Každý z nás, kdo pracuje s Javou nějaký ten čas, se tu a tam potýká s tímto těžkopádným API. Joda Time přinesl poměrně hodně nových myšlenek a stal se základem pro JSR 310, které by mělo být součástí nové Javy 7.
Integrační testy spočívají v testování konkrétní kódu spolu s okolními částmi, se kterými spolupracuje. Cílem je snaha otestovat kód ve stavu, který se blíží reálnému nasazení. Obvykle takto testujeme datovou vrstvu aplikace (jelikož tam klasické jednotkové testy ztrácejí smysl - chceme přeci otestovat správné dotazování databáze, tudíž databázi k testu potřebujeme) a v řadě případů se nám nevyplatí mockovat ani na úrovni business vrstvy. Dokonce i Rod Johnson ve své prezentaci (kterou byl inspirován tento článek) zdůrazňuje důležitost integračních testů.
This presentation was prepared formerly for internal purposes of Norkom Technologies in Ireland by my old friend Pavel Jetenský. We appreciate that authorities of this company allowed us to make the presentation public so you can benefit from it as well. I also thank Pavel for preparing this presentation and for providing support to me with finalizing material to be published.
The training shows how to jUnit test J2EE application based on Spring and Hibernate.
Jistě jste také už mnohokrát, stejně jako já, řešili problém, jak spolehlivě automaticky otestovat, že vaše aplikace správně odeslala email s konkrétním obsahem na konkrétní emailovou adresu. Problém je to zapeklitý a dosud jsem ho dokázal řešit jen těmito způsoby:
udáním testovací schránky a automatickým výběrem této schránky (např. přes protokol POP3) vytvořením mock objektu, který mi zastoupil třídu starající se o odeslání emailu (tzn. k žádnému emailu fyzicky v testu nedošlo) Oba dva přístupy mají svá úskalí.
Řada z vás možná už na výraz Mock testing narazila, někteří ne. Pro ty z vás, kteří Mock přístup v testování nepoužili je tento článek. Pro ostatní může být zajímavá ukázka této techniky na knihovně EasyMock.
Co jsou to mock objekty? Jedná se vlastně o techniku psaní určitého druhu automatických testů. V podstatě se jedná o nahrazení reálného objektu testovací fasádou, která neprovádí žádnou funkcionalitu nahrazovaného objektu - jen se jako tento objekt tváří.
