Nástroje SoapUI a JMeter

Uvedené nástroje používám již několik let a myslel jsem si, že jsou natolik známé a rozšířené mezi programátory, že ani nemá cenu se psát, jestli je někdo zná. Překvapivě jsem se mýlil.

JMeter je nástroj pro měření výkonnosti a pro vytváření umělé zátěže na webových projektech. Je to spíše nástroj "pro začátek" - tím myslím to, že kdo opravdu řeší problematiku výkonnosti, robustnosti a škálovatelnosti aplikací, tak asi bude používat jiné, komerční nástroje. Já si většinou pouze chci ověřit, že mnou napsaná aplikace běhá dle očekávání, že tam není vyloženě nějaký problém třeba v konkurenčním přístupu více uživatelů apod. V tomto ohledu naprosto dostačující nástroj.

Bez nástroje SoapUI si vývoj webových služeb vůbec nedovedu představit. Vždy když se vytvoří nová webová služba nebo se nějaká již existující integruje, tak je potřeba si ověřit komunikaci pomocí nějakého klienta. SoupUI není pouze klientem webové služby, ale celkem sofistikovaný nástroj pro jejich vytváření a testování.

Oba dva nástroje jsou samozřejmě open-source, tedy zdarma.

Znáte Daisy?

Mě tento CMS nástroj doporučil kolega, já ho úspěšně použil pro jednoho zákazníka a tak pozitivní zkušenost šířím dál.

Je to již nějaký čas, co jsem Daisy používal, ale zrovna minulý týden se na mě kamarád obrátil pro radu, tak jsem si na Daisy znovu vzpomněl.

Na Daisy jsem oceňoval hlavně tyto věci:

• aplikace je napsaná v Javě, takže pro mě není problém aplikaci kustomizovat


• přišla mi velice intuitivní, takže jsem se s tím velice rychle naučil


• udělal jsem tam vše, co jsem potřeboval - zákazníkovi jsme pomocí Daisy vytvářeli skladiště dokumentace k projektům. Bylo tedy potřeba vytvořit nějakou základní strukturu úložiště pro uložení dat včetně nastavení přístupových práv. Vložené dokumenty (zejména MS Word) se automaticky indexují a lze přes ně fulltextově vyhledávat. Daisy je natolik uživatelsky přívětivé, že zákazník po zaškolení používá aplikaci sám.
  

Ve svých poznámkách jsem našel jedinou nevýhodu, se kterou jsem se potkal - měl jsem občas problém s češtinou při fulltextovém vyhledávání (používal jsem verzi 2.1). Neměl jsem čas a ani prostor to moc řešit, takže ani nevím, jak to dopadlo.

Open-source ESBs

Integrace, SOA, ESB - to jsou buzzwords poslední doby. Není to jen módní vlna, která hlavně vychází z marketingových snah velkých firem, ale také realita současnosti - existuje spousta starých či nových systémů, které je potřeba propojovat. Pokud je těch systémů více (více jak 5), tak už nemá cenu to propojovat přímo mezi sebou, ale využít nějaké ESB řešení.

Pro náročná řešení a náročné zákazníky máme v portfóliu naší firmy produkty od IBM - WebSphere Process Server, WebSphere Integration Developer a WebSphere Enterprise Service Bus.

Kromě toho ale potřebujeme i dostupná řešení pro širokou škálu zákazníků, takže jsem se začal dívat po nějakých open-source ESB řešeních. Dal jsem dohromady krátký seznam řešení, na která jsem narazil spolu s body, které mě zaujaly. Hned říkám, že žádné praktické zkušenosti s uvedenými systémy nemám a za jakékoliv informace tohoto typu budu velice rád.

MuleESB

• URL: http://www.mulesource.com, http://www.muleforge.org
• konfigurace pomoci Springu, systém postaven nad Springem
• velice úspěšný a rozšířený open-source projekt (7 firem z fortune 50)
• kromě ESB mají další produkty zaměřené na SOA. Některé z nich jsou dostupné v rámci podpory.
• OSGi ready
• MuleForge - web pro hostování projektu pro Mule rozšíření, např. různé konektory k systémům třetích stran

JBoss ESB

• URL: http://www.jboss.org/jbossesb/, http://www.jboss.com/products/platforms/soa
• podpora od české firmy - lokální partner firma Servodata
• možnost školení v češtině
• postaveno na základech Rosetta ESB, které JBoss získal v roce 2006. Rosetta ESB je prověřené řešení vyvinuté a používané ve velké Kanadské pojišťovací společnosti.
• součástí podpory jsou i nastroje pro monitorování a další věci, které normálně volně dostupné nejsou
• actions mohou byt instalovány/odinstalovány za běhu
• JBoss nabízí celkem velké portfolio technologií a platforem, se kterými se dá vystavět aplikace od A do Z včetně integrace

WSO2 ESB

• URL: http://wso2.com/products/esb/, http://synapse.apache.org/
• řešení je postaveno nad Apache Synapse, pouze je rozšířeno o administrátorské rozhraní. Autoři WSO2 ESB jsou i autory Apache Synapse.
• jednoduché, malé řešení určené zejména pro mediace a transformace zpráv, není k dispozici orchestrace.

OpenESB

• URL: https://open-esb.dev.java.net/
• Uvádím jen pro úplnost, ale s ohledem na předchozí řešení mi toto již nepřipadá tolik zajímavé, a proto jsem ho dal pryč z užšího výběru.

Závěr

Ještě jsme nic nevybrali. Není to ovšem vždy jen o technologické úrovni, ale hodně také o politice - jaké naše firma má partnery, koho můžeme podporovat a koho ne atd.
Mě je zatím nejsympatičtější ESB od Mule. Proč? To nedokážu přesně popsat, zatím jen pocit :). Finální výběr vidím mezi MuleESB a JBoss ESB. Apache Synapse se mi moc libí hlavně z toho důvodu, že je to malé, lehké řešení a to že nemá orchestrace zase tak vadit nemusí, na to jsou větší řešení (říká se, že dává smysl něco orchestrovat pro více než 5 služeb což odpovídá spíše středním firmám). Proti mluví to, že nemá cenu se učit tolik systému (něco pro velké zákazníky, něco pro střední a něco jen pro lehké věci), proto asi Synapsi také vyřazuji z výběru.

Komentovat? Určitě ano.

Opět jsem se setkal s názorem, že komentovat zdrojové kódy není potřeba, že kód sám o sobě je dokumentace. K tomu můžu říci jen jedno - to je naprostá blbost.

Stačí nepracovat s vlastním kódem několik týdnů a už člověk ztrácí přehled o jemných detailech algoritmů, které sám psal. Nemluvě pak o tom, když je potřeba opravit chybu v rok staré aplikaci a nebo pracovat v kódu svých kolegů.

Také jsem slyšel "Jsem orientovaný na výkon a psaní komentářů mě brzdí". To je hodně krátkozraké, protože možná je člověk o pár minut rychlejší, když implementuje algoritmus, ale z dlouhodobějšího pohledu je to samozřejmě krátkozraké - čas strávený nad zjišťováním, jak jsem to já nebo můj kolega vlastně tehdy mysleli, je mnohem větší než kolik se dá ušetřit na jednom algoritmu bez komentářů. Ale já bych se vůbec do těchto polemik nepouštěl, protože dle mého názoru zdrojový kód se automaticky rovná kód plus komentáře.

Při psaní komentářů je potřeba nezapomínat, že zdrojové kódy nejsou Java soubory, ale také třeba konfigurační soubory, soubory prezentační vrstvy atd. To jsou také zdrojáky a ty je potřeba také komentovat.

Opačný extrém je takový, že na jeden řádek kódu připadají dva řádky komentáře. Není potřeba komentovat to, co je zřejmé z vlastního kódu. Zdrojový kód je jako dobrodružná knížka, kde jazyk Java popisuje vlastní děj příběhu. Komentáře jsou pak dějová vysvětlení, aby se čtenář v jednotlivých zápletkách neztratil. Pokud je toho vysvětlování příliš na úkor vlastního děje, tak pak to asi moc záživná knížka nebude.

Máte čas na unit testy?

Pokud bych si měl hned sám odpovědět, tak dle mého názoru moc času není. Není z jednoho hlavního důvodu a to jsou peníze resp. náklady plynoucí z času, který bude věnován psaní unit testů. Hned na začátku také musím dodat, že celý článek je o "normálních" jednorázových projektech, které nejsou nějak mission-critical. U vývoje produktu (tj. aplikace, kterou zabalím a pošlu zákazníkům nebo aplikace, kterou opakovaně dodávám) předpokládám, že bude prostor pro psaní testů mnohem větší.

Ještě jsem nedělal ve firmě, kde by se počítalo s tím, že N dní budu vyvíjet produkční kód a dalších N dní budu mít vyhrazeno na testování (pozn. píši to sice v pořadí produkční kód, testy, ale klidně je možné si představit přístup opačný - TDD). Takto to často prezentují agilní přístupy k vývoji softwaru, ale v praxi je dle mého názoru toto neuskutečnitelné, aspoň tedy v rámci projektového vývoje, protože poměr nákladů na psaní unit testů vs. přínosy z toho plynoucí nejsou zrovna moc pozitivní.

V žádném případě nejsem odpůrce psaní testů, ale realita mě nějak naučila se na tu problematiku dívat i z jiného pohledu než jen vývojářského. Vidím spoustu výhod ze psaní testů, zejména následující dva:

• zajištění požadované kvality produkčního kódu
  
• kvalitou se nemyslí jen kód bez chyb, ale i takové věci, jako kvalitní architektura aplikace, dobrá dekompozice problému apod. Pokud chci psát efektivně testy, tak pak potřebuji mít i dostatečně kvalitní produkční kód.

Samozřejmě bez testů to nejde, nedovedu si představit, že bych takto odevzdal aplikaci zákazníkovi. Ale na jaké testy se zaměřit, aby přínosy a náklady byly v rozumné rovnováze? Dle mých zkušeností jsem asi nejlepší poměr přínosy vs. náklady zaznamenal v těchto případech:

• znovupoužitelný kus kódu (knihovna, modul)
  
• stěžejní aplikační logika, např. jádro aplikace
  
• doménové objekty - equals. Na to jsou již testy napsané, takže je jen použít. Přínos možná malý, ale ušetří spoustu času při hledání chyb s kolekcemi.
  
• při použití ORM nástroje testovat základní CRUD operace nad objekty. Pro tyto účely jsem si napsal sérii testů, protože je to stejné pořád dokola a je dobré vědět, že práce s DB na té základní úrovni funguje jak má. Spíše je to testování ORM mapování jako celku, než jen samotného procesu ukládání dat do DB.

Naopak mám negativní zkušenost z Mock (jMock, EasyMock) testů servisních a jiných interních rozhraní v aplikaci. Přínosem určitě bylo to, že mi testy drží strukturu aplikace pohromadě, ale velkou nevýhodou byla ztráta flexibility - kdykoliv jsem provedl nějaký refaktoring, tak jsem musel měnit i tyto testy. Testy se musí měnit vždy s ohledem na změny produkčního kódu, ale v oblasti rozhraní se mění a přidává celkem hodně a dle mého názoru výhody nepřevažují nevýhody.

Speciální kapitolou je testování GUI. Již jsem se na toto téma jednou rozepsal, kde jsem porovnával nástroje pro unit testy GUI. Bohužel je dost často rychlejší tedy levnější nechat GUI testy provést manuálně, než testy vytvořit a testovat automaticky. Většina si hned asi v duchu řekne, že je to možná levnější během vývoje, ale z pohledu nasazení, údržby a podpory aplikace to už neplatí. Toto je asi pravda, ale těžko se to prosazuje v průběhu vývoje. Úplně nejlepší je zapojit do testování zákazníka. Snažíme se vyvíjet iteračním způsobem a vždy na konci každé iterace dáme hotovou část aplikace zákazníkovi, který to následně připomínkuje.

Mě by hodně zajímalo, zda můj pohled na věc odráží realitu současného vývoje aplikací nebo zda jsem mimo. Znám spoustu firem resp. kolegů, kteří ještě nenapsali ani čárku testovacího kódu, ale na druhé straně znám i firmy, kde se na testování klade velký důraz. Já bych sám rád testoval určitě více než doposud, ale ekonomické tlaky od obchodníků, projekt managerů a vedoucích mi to moc nedovolují.