Testování EJB komponent

Všeobecně známý fakt, že se EJB komponenty špatně testují, je postaven zejména na tom, že neexistuje žádný standardní způsob, jak při psaní testů postupovat. Pokusím se sepsat způsoby, jak tento palčivý problém vyřešit.

O tom, že je testování důležitá část vývoje, nemá smysl polemizovat. V poslední době se na české scéně objevilo několik článků: "proč je testování důležité". Osobně zastávám názor, že bez testů nemohu kód považovat za funkční a jeho nasazení je velký risk, který se násobí následným refaktoringem či řozšiřováním stávajícího kódu.

V následujících odstavcích se budu zabývat jen EJB 3.0.

Způsoby testování bych rozdělil na 2 typy: testování uvnitř aplikačního serveru a mimo něj.

Testování uvnitř aplikačního serveru

Tento způsob má tu výhodu, že dané testy se mohou začít psát bez jakékoli další pomůcky pro inicializaci EJB kontejneru a služeb v něm. Ohromnou nevýhodou je ovšem to, že samotné psaní a spouštění testů je přímo závislé na nastartování a nahrání celé aplikace na server. Tato činnost může při větších projektech trvat řádově i několik minut. V takové chvíli může vývojář získat naprostý odpor k testování.

Způsob, jak testovat EJB komponenty uvnitř AS, je použití vzdáleného volání EJB komponent. Nevýhodou je ovšem to, že při návrhu musíte definovat "remote" rozhraní.

Druhým způsobem je testování přímo v EJB komponentě, kde mohu pomocí DI (dependency injection) získanou EJB komponentu otestovat. Nevýhodou je zde to, že tento způsob již překračuje základní způsoby testování. JUnit či jemu podobný framework je v takovém případě nepoužitelný.

Testování mimo aplikační server

První velkou nevýhodou tohoto řešení je samotný fakt, že nějak musíte nahradit EJB kontejner. Asi nejznámějším řešením je použití Embedded JBoss.Tento způsob vyžaduje, aby vaše aplikace byla schopná běžet pod JBoss AS, a abyste použili JVM 1.5 (na novejších verzích bohužel embedded JBoss nespustíte). Pokud aplikaci vyvíjíte pod jiným aplikačním serverem, budete s tímto mít asi problémy. Například už jen z důvodu samotné nestandardizace JNDI či použitých nekompatibilních vlastností pro Java EE 5.

Druhým způsobem, jak umožnit testování EJB komponent mimo aplikační server je, že použijete framework typu Ejb3unit, který na základě vaší definice EJB komponent sám provede dependency injection a další vlastnosti typické EJB kontejneru. Nevýhoda tohoto řešení spočívá v tom, že má příliš mnoho omezení, která poté mohou zbytečně ovlivňovat návrh business vrstvy. Na stránkách je možné se dočíst, že brzy vyjde verze 2.0, která snad přinese slibované vlastnosti.

Posledním způsobem, jak vyřešit testování, je použití vlastního řešení. Jelikož používám jako aplikační server Glassfish, byl pro mne JBoss Embedded tabu. Jelikož mám i uvnitř EJB komponent občas složitejší architekturu (dělené vrstvy), tak Ejb3unit byl nepoužitelný.

Můj vlastní způsob spočívá v tom, že testuji EJB komponenty, které obsahují vazby na další EJB pomocí anotací @EJB či vstřikují pomocí @PersistenceContext EntityManager (+ občasné delegování na Hibernate Session).

Jinými slovy, řídím EJB pomocí anotací, což mi umožňilo napsat si i vlastní řešení na testování. Moje řešení totiž využívá Java reflection API, přes které provádím jak dependency injection dalších EJB komponent, tak samotné DI EntityManageru a dalších zdrojů, které zrovna potřebuji.

Test poté vypadá jednoduše: "při inicializaci pošlu testovanou EJB komponentu do metody, která mi vrátí instanci samotné EJB komponenty i s inicializací potřebných závislostí".

Zatím jsem nenalezl lepší řešení. Pravdou je, že v této oblasti jsou EJB komponenty nechány napospas vývojářům, což s sebou přináší jen nekompatibilní způsoby testování jednotlivých částí aplikace.

Doufám, že Glassfish V3 přinese slibovanou možnost být "embeddable" v plném rozsahu či někoho v SUNu napadne s tímto problémem něco udělat. Zatím mi přijde, že každý si napíše vlastní řešení, protože kromě JBoss Embeddable jsem nenašel nic, co by alespoň trošku splňovalo mé požadavky.

Pokud má někdo zkušenosti i s dalšími možnostmi testování EJB komponent, nechť se o ně podělí v komentáři, děkuji.

NetBeans 6.1 a Facelets plugin

O tom, že vyšly Netbeans 6.1 se nemá smysl zmiňovat. Ovšem výhodou této verze je zejména její rychlost, na kterou se údajně vývojáři nejvíce zaměřili.

Jedna věc mi ovšem zde chyběla. A to opět plugin pro facelets :)

Naštěstí existuje řešení, jak daný plugin dostat do této verze.

Následující text je spíše dočasný, tzn., že  až vyjde oficiální podpora, jistě bude lepší použít přímo ji.

Na stránce https://nbfaceletssupport.dev.java.net/ je k dispozici cvs repozitář. Z daného repozitáře stačí provést checkout projektu a daný projekt "nbfaceletssuite" otevřít v NetBeans 6.1. Dané pluginy poté zbuildovat a provést create nbm. Tyto pluginy jsou poté schopny pracovat ve verzi 6.1.

Pak již stačí pluginy nainstalovat a máte k dispozici starou dobrou (i když ne zrovna plnou)  code completion v xhtml souborech :)

Glassfish V3 bude embeddable

Minulý týden mi v rss čtečce přistál článek od Kohsuke Kawaguchi, že Glassfish V3 bude "embeddable".

Osobně jsem si přesně toto pro Glassfish přál. Představte si, že budete mít EJB projekt, který budete moci spouštět např. v Tomcatu. Že budete moci testovat EJB, aniž by bylo potřeba provádět deploy na server či používat remote call EJB či používat "nepoužitelné" frameworky jako je EJBUnit (i když uvidíme jak dopadne verze 2.0). Vše co obsahuje specifikace Java EE 5 a vše co implementuje Glassfish je tedy možné provozovat aniž by někde musel běžet daný server.

V současné době se touto možností může chlubit JBoss AS či Jetty, nyní již stačí počkat pár měsíců (možná týdnů do testovací fáze) a bude možné to samé dělat s GlassFish.

Díky modularitě tohoto AS je ovšem možné startovat server v řádech několika milisekund, což narozdíl od JBoss AS je podstatný rozdíl :)

Před nějakým časem jsem chtel Glassfish opustit a jít cestou JBoss, ale asi ještě chvíli počkám, je vidět, že konkurenční prostředí je prostě ideální stav.

Teď nezbývá, než držet palce, ať se dané featury dotáhnou do úspěšného konce.