GUTs = good unit tests

K problematice testování jsem četl výborný článek (1, 2) na JavaWorld, který všem vřele doporučuji - nejen kvůli obsahu, ale i kvůli množství odkazů na další články a zajímavé knihovny.

K obvyklým a častým "best-practices" (např. JUnit best practices) bych ještě přidal z mých zkušeností následující:

• testovací kód by měl splňovat stejné kvalitativní nároky jako produkční kód. Místo jedné dlouhé testovací metody, která navíc ještě obsahuje duplicitní kód střídající se v jedn. testovacích metodách, je vhodné společný kód vyčlenit do separatních metod nebo i tříd, aplikovat pravidla refactoringu, když už kód "začne smrdět" (1, 2).
  
• testy jsou ukázkou použití produkčního kódu, testy jsou součástí popisu API aplikace.
  
• jednotlivé testy musí být na sobě nezávislé, pořadí spouštění testů může být libovolné
  
• otestovat lze (skoro) všechno, jen je potřeba najít rovnováhu mezi náročností napsání testů a jejich přidanou hodnotou. Nesnažit se tedy za každou cenu dosáhnout 100% pokrytí produkčního kódu testy, ale spíše se držet pravidla 20/80, kdy otestováním 20% kódu otestujeme 80% funkcionality.
  
• testy nesmí mít žádné vedlejší efekty, např. přidaný záznam v DB.
  
• při psaní testů se nespoléhat na konkrétní prostředí (Locale, adresář na lokálním disku apod.), protože testy se mohou spouštět kdekoliv.
  

Co mě ale v uvedeném článku nejvíce zaujalo byla knihovna hamcrest. Při psaní testů jsem měl pořád problémy se psaním smysluplných komentářů do assertů a navíc mi ty všechny kontroly nepřisly úplně přehledné, když toho bylo více. Toto vše řeší hamcrest díky jednoduchému a výstižnému API - na ukázky a možnosti se podívejte do tutorialu nebo do uvedeného článku.

Komponenta pro vyhledávání, třídění, stránkování, ...

Vyhledávání záznamů a jejich zobrazení je tak často se opakující věc, že by se zdálo, že už to má každý vyřešený. Bohužel tomu tak není, některé problémy se opakují pořád dokola - je nutné zobrazovat celkový počet záznamů? Je nutné mít možnost přejít na poslední stránku výpisu? Je možné, aby se v průběhu stránkování nebo třídění měnila data? Stačí parametrické vyhledávání nebo je nutný fulltext? Těch otázek je mnoho a co aplikace, tak to trochu jiné (specifické) požadavky zákazníka.

Ve firmě, kde nyní působím, se snažíme najít vhodné řešení na následující požadavky spojené s vyhledáváním:

• řešení by ideálně mělo implementovat prezentační, tak i datovou vrstvu. Tedy zobrazení dat a i jejich načtení.
  
• zobrazená data by mělo jít filtrovat, třídit, stránkovat
  
• použitelné v JSP
  
• nezávislé na zvoleném MVC řešení. Pokud závislé, tak pouze na Spring MVC
  
• na datové vrstvě podpora JDBC a Hibernate
  

Takové řešení znám zatím pouze jedno a jmenuje se ValueList. Tento projekt (již přes dva roky neaktivní) vychází z implementace J2EE patternu ValueListHandler. Poslední verze je 0.1.8, ale i přesto je použitelná. Ve firmě to používají již nějaký pátek, ale pořád to není ono, pořád je nutné řešit nějaké problémy kvůli specifickým požadavkům té konkrétní aplikace. Super ale je, že se analytické, vývojářské a grafické oddělení bylo schopno domluvit na jednom řešení, které se používá a všichni o něm vědí.

Já osobně toto řešení nepovažuji za zcela šťastné. Když pominu to, že ValueList obchází standardní strukturu několika-vrstvé aplikace (data se načtou a pak se hned zobrazují), tak mi přijde, že mě to příliš svazuje. Jak jsem již naznačil, někdy potřebuji fulltext, někdy musím zaručit neměnnost dat při stránkování, někdy tahám data z více datových zdrojů atd. Chci tím tedy říci, že nevidím velkou přidanou hodnotu v jednotném řešení na datové vrstvě, ale zejména na prezentační vrstvě, protože tam je to pořád stejné (až na úpravy vzhledu pomocí stylů).

Pro čistě prezentační vrstvu se hodí DisplayTag, který se zdá být hodně zajímavý. Jako vhodnou cestu tedy vidím v použití nějaké komponenty jako DisplayTag s rozšířením o filtrování a podpoře na úrovni MVC (ať nemusím pořád řešit převod parametrů komponenty na interní datovou strukturu, podle které pak vyhledávám) a s tím, že datovou vrstvu si budu řešit dle potřeby. Pro časté scénáře mohu mít nějakou podporu v datové vrstvě, ať se vše nemusí řešit od nuly.

Rád bych se zeptal, jak tuto problematiku řešíte vy? Máte nějaké osvědčené interní řešení nebo to řešíte v každé aplikaci znovu a znovu?

Java Web Start vs. "normální" web

Minulý týden jsem se snažil napsat porovnání technologie Java Web Start s "normálními" webovými technologie jako jsou JSP, JSF, Velocity atd. Nešlo mi tedy o konkrétní webovou technologii, jako spíše o porovnání dvou světů.

Porovnání bylo pro mého kamaráda, který by rád určitou aplikaci a má představu, že JWS by mohlo být to pravé. Já sám se mu snažím nějak vysvětlit, že přeci jen "lehké" webové technologie jsou lepší. Ještě také dodám, že cílová aplikace bude interní resp. intranetová aplikace s max. počtem uživatelů okolo padesáti, určená pro správu několika registrů.

Web

• + máme znalosti pro vývoj webových aplikací, HTML, CSS umí skoro každý
  
• + lépe se bude navrhovat design
  
• + spoustu věcí jsme již řešili, takže celkem významná znovupoužitelnost kódu a řešených problémů
  
• + webový prohlížeč je snad na každém počítači, min. nároky na výkon počítače
  
• + ovládání prohlížeče je běžná záležitost => pokud vytvoříme "standardní" webovou aplikaci, tak by běžný uživatel neměl mít problém
  
• + lehce spravovatelná aplikace z pohledu nasazování nových verzí
  
• + na jednotlivé stránky lze odkazovat a tyto odkazy se mohou posílat mezi uživateli
  
• + dnes je jednoznačný trend přesunu aplikací do webového prohlížeče (např. Google Docs). Pomocí webových technologií lze dnes vlastně udělat aplikaci, která bude vypadat stejně a chovat se stejně jako desktopová aplikace.
  
• - webové aplikace jsou bezstavové, takže nelze vytvářet (jednoduše) věci jako v desktopové aplikaci, navíc webové prostředí má své běžné problémy (návrat na předchozí stránku, refresh stránek po odeslání formuláře apod.). Vše lze ale nějak řešit.

Java Web Start

• + centrálně spravovaná desktopová aplikace spouštěná přes JNLP (HTTP) protokol - je možné si např. dát odkaz na plochu počítače
  
• - vývoj desktopové aplikace je složitější, navíc s ním nemáme moc zkušeností => vývoj bude nákladnější
  
• - u JWS musím řešit navíc komunikaci klienta a serveru (pokud tedy bude oddělena logika a vlastní vzhled aplikace). Toto není u "normální" webové aplikace potřeba.
  
• - při prvním spuštění nebo při nové verzi je vždy potřeba stáhnout celou aplikaci, takže to chvíli trvá dle rychlosti připojení k internetu
  
• - uživatelé chtějí data na webu, takže je potřeba mít jednu aplikaci na správu dat a pak jinou aplikaci na její prezentaci, což je neefektivní a nakonec i daleko dražší z pohledu vývoje

Budu rád, pokud mě doplníte nebo v něčem opravíte...

Srovnání systémů na správu chyb

Kamarád se na mě obrátil s dotazem, zda bych mu mohl doporučit nějaký systém na správu chyb. Vzpomněl jsem si, že jsem si kdysi (asi před rokem) dělal takový malý osobní průzkum a dokonce jsem k tomu našel i nějaké poznámky, které bych teď rád zveřejnil (doufám, že všechny uvedené informace jsou stále platné).

Bugzilla

URL: http://www.bugzilla.org

Výhody:

• hodně používaný systém, prověřený open-source komunitou – existuje dostatek informací na fórech, v dokumentaci
  
• existence spousty rozšíření – integrace s dalšími nástroji jako je SVN, různí klienti mimo základní webový klient. Více informací je zde.
  
• existuje (aspoň částečný) český překlad
  
• bugZilla je po instalaci připravena k použití, co se týče dat pro zadávání bugů. Obecně lze říci, že bugZilla je řešení v kostce, které pokrývá základní požadavky na bug tracking systém. Pokud chceme určité věci jinak (např. jiné schvalovací workflow, tak už je to problém)

Nevýhody:

• ne moc „sexy“ vzhled. Toto hlavně platilo pro verze 2.x, nyní od verze 3.x je to lepší a mělo by to být dokonce skinovatelné.
  
• komplikované nastavování uživatelských práv – kdo co může vidět, editovat apod. Zkušenost z verze 2.x, ve verzi 3.x opět vylepšeno.
  
• struktura bugu je dána, není možné příliš konfigurovat
  
• nástroj určen převážně pro interní použití, není vhodné to vystrkovat směrem k uživateli

Poznámky:
BugZilla nabízí demo k vyzkoušení.

Scarab

URL: http://scarab.tigris.org/

Výhody:

• Scarab není jen systém na evidenci chyb, ale obecně artifaktů – to můžou být požadavky, chyby, nové věci k realizaci.
  
• Scarab je hodně konfigurovatelný. Základní instalace obsahuje definici základních typů, které je možné změnit, přidat, upravit.

Nevýhody:

• Produkt není úplně bez chyb, je ve verzi 0.21. Když se ale ví jak ho používat, tak žádné problémy nejsou.

Trac

URL: http://trac.edgewall.org/

Výhody:

• Výborná integrace se Subversion.
  
• Jednoduché a dostačující řešení pro menší projekty a týmy, nesnaží si hrát na velký systém. Z pohledu uživatele je to tedy srozumitelný, nezatěžuje ho složitost toho co nepotřebuje (např. bugZilla).
  
• Postaveno nad Wiki

Nevýhody:

• Také asi nelze čekat aplikaci bez chyb (aspoň dle čísla verze).

Poznámky:
I zde je demo k vyzkoušení.

JIRA

URL: http://www.atlassian.com/software/jira/

Výhody:

• Z pohledu použitelnosti, možnostech nastavení se jedná jednoznačně o nejlepší řešení
  
• Nejedná se pouze o bug tracking systém, ale lze to využít např. i pro projektové řízení

Nevýhody:

• Jedná se o placený software, základní verze začíná na ceně $1200.
  
• Je primárně určen na větší projekty (nejen svojí robustností, ale i schopností se integrovat s dalšími systémy) – většinu z toho vůbec nevyužijeme.

Závěr

Osobní zkušenost mám se systémy bugZilla, JIRA a částečně Scarab. Pokud bych nemusel hledět na peníze, tak bych si určitě zvolil JIRA – nabízí toho určitě nejvíce ze všech, uživatelsky přívětivé prostředí, velká síla je ve velkém množství reportů.

Nejvíce znám a používal jsem systém bugZilla. Nemůžu říci, že bych s ním byl nespokojený, to co jsem od něj požadoval, tedy správu chyb, tak to plnil bez chyb. Dost často jsem slyšel narážky na její vzhled, zejména v době, když jsme potřebovali zapojit do našeho systému i externí zákazníky. Třetí verzi bugZilly jsem jen viděl nebo o ní četl a myslím, že se tam ty základní problémy (vzhled, nastavení práv) zlepšily.

Hodně příjemně na mě zapůsobil Trac – jednoduchý nástroj postavený na Wiki, který nabízí přesně to, co se od něj očekává. Pokud bych měl tu možnost, tak bych rád Trac použil na nějakém projektu, zatím je to takový můj černý kůň.

Pokud bych nechtěl nic pokazit a musel bych vsadit na jistotu (a neměl bych peníze), tak bych volil bugZillu.

Ještě bych nakonec odkázal na porovnání uvedených nástrojů v článku na JavaWorld.

Jakou verzi Javy používáte? - výsledky

V poslední anketce mě zajímalo, jakou verzi Javy používáte. Zajímalo mě to hlavně kvůli tomu, že ještě před 3 lety jsem pracoval na projektech v bankách, kde se používala Java 1.3. Tak mě zajímalo, zda je to jen výjimka a nebo zda je to normální.

Zde jsou výsledky (celkem hlasovalo 180 lidí):

1. Java 6 (67%)
   
2. Java 5 (40%)
   
3. Java 1.4 (10%)
   
4. Java 1.3 (1%)
   
5. Java 1.2 (1%)
   

Já osobně pořád spíše používám Javu 5, ale nemám vlastně pro to žádné objektivní důvody, spíše jsem pohodlný a neměl jsem zatím důvod přecházet na Javu 6.

Výsledky asi nemá cenu ani komentovat, protože jsou dle očekávání. Sice si pořád myslím, že v bankách a jiných velkých institucích se jede na Jave 1.4 a starších ve větší míře, než jak ukazují výsledky, ale je to jen má domněnka. Na závěr si neodpustím otázku - nedovedu si vůbec představit, proč se někde ještě dnes musí využívat Java 1.3 nebo 1.2? Aspoň doufám, že jde o nějaké staré projekty stále v údržbě.