24. září 2011

Zkušenosti ze zavádění testování

Bude to již skoro dva roky, kdy jsem začal zavádět testování ve firmě (viz článek Největší problémy při zavádění testování). Teď jsem se dostal do stavu, že si potřebuji vše zpětně zhodnotit a posunout to ve firmě zase o kousek dále.

Co se povedlo:

  • základní principy a přínosy testování zná v týmu snad každý, každý až na nějaké výjimky již má zkušenosti s napsáním vlastních testů. V tomto ohledu se to rozjíždělo pomaleji než jsem na začátku čekal, trvalo chvíli než se dostavil efekt sněhové koule. Nejdříve jsem psal testy jen já, pak se začali postupně přidávat po jednom další a další až nyní je nás většina. Ovšem samozřejmostí je to pořád jen pro pár lidí. Také pomohlo několik případů, kdy nebylo jiné možnosti než napsaní aut. testů, protože ruční vytváření testovacích dat bylo strašně moc komplikované a zdlouhavé.
  • technické řešení resp. podpora pro psaní testů byla již od samého počátku hotová, v průběhu těch dvou let jsem toho zase tolik nemusel přidávat. Naše řešení je postavené nad vlastním frameworkem pro vytváření testovacích dat (viz článek Vytváření testovacích dat), doplněné o některé zajímavé vychytávky pro snadnější psaní testů - Testování webových služeb nebo Plošné vypnutí povinného @Autowired.
  • téma testování se začíná ve firmě prosazovat, nejen ve vývoji, ale zejména v konzultantské části firmy. V tomto ohledu také nastává posun z manažerského pohledu - ze začátku bylo testování, dle mého názoru, podporováno hlavně kvůli tomu, že o tom hodně lidí mluvilo, a že jsem byl schopen říci jak s testováním začít, jak to celé uchopit. Nyní je to spíše o snaze celé testování více zefektivnit, případně začít více měřit. Je tedy např. snaha o lepší spolupráci mezi konzultanty (zadavateli úkolů) a vývojáři tak, aby již zadání obsahovalo podpůrné informace pro co nejefektivnější psaní unit testů, které by ve výsledku měli ulevit právě konzultantům.
  • testy jsou součástí automatického buildu
Co se nepovedlo:
  • stále jsou zarytí jedinci, kteří testování "odolávají". Neustálá argumentace a úsilí mě celkem vyčerpává, ale je to vlastně má jediná zbraň, takže musím vydržet
  • bylo ode mě na začátku celkem naivní si myslet, že když někdo "prasí" produkční kód, tak testy na tom budou lépe. Spíše naopak. Testy jsou prostě považovány za něco "méně kvalitního", co nepotřebuje komentáře, vše se může psát bez nějaké struktury pod sebe. Tento bod nesouvisí nejen s testy, ale je to spíše úkol pro celý tým - používat a dodržovat konvence pro psaní zdrojového kódu.
  • unit testy fungují víceméně jako nástroj vývojáře, aby si svůj kód alespoň párkrát spustil a ověřil, že to plus mínus funguje. Z mého pohledu je potřeba zlepšit předávané informace od konzultantů, aby již v zadání úkolů byly uvedeny informace na co je vhodné se během testování zaměřit tak, aby to v konečném důsledku pomohlo nejen vývojářům, ale i konzultantům, kteří to vše musí převzít a sami ověřit, že je implementace správná.
  • chybí nám měřitelná zpětná vazba, neumíme říci, že díky pokrytí určité části testy se zlepšila chybovost o tolik a tolik. Neumíme říci, zda vynaložený čas na psaní testů je v konečném důsledku opravdu přínosem nebo není. Já jako vývojář vím o hodně výhodách a bez testů si to už nedovedu představit, ale má podobný názor i vedení? Obávám se, že zatím ne.
  • od začátku jsme chtěli, aby se testy co nejvíce efektivně, tj. psát testy jen k tomu, kde to má přidanou hodnotu. Vymysleli jsme to tak, že každý kdo bude chtít psát nějaké testy, tak přijde za mnou a zkusí mě přesvědčit, že daný test má smysl. Na první pohled dobrý nápad, ale ve výsledku špatné - potřebovali jsme motivovat vývojáře ke psaní testů a ne jim házet klacky pod nohy. Od tohoto jsme postupně opustili, bohužel zase mám někdy pocit, že některé testy mi nepřijdou moc efektivní. Ale asi je lepší mít více testů než méně.
Co dále v nejbližší době?
  • v rámci code review se více zaměřím právě na testy
  • chtěl bych zlepšit dokumentaci testů resp. JavaDoc testů. Jsem toho názoru, že každý by měl umět před implementací metody popsat, co daná metoda bude dělat. Pokud toho není schopen, pak vlastně přesně neví, co daná metoda má dělat. To samé platí o testech - každý si musí před každým testem říci, co chce testovat, jaké budou vstupy a jaké očekávané výstupy. Zde bych to chtěl nějak standardizovat, ale ještě nevím jak - nějaká jednotná JavaDoc šablona nebo nějak úplně jinak? Budu rád za nápady, jak se to řeší jinde.
  • musím zrychlit běh testů na build serveru. Je pravda, že build server je přetížený, ale i tak je hodně, pokud nám celý build včetně všech testů běží skoro hodinu. Zpětná vazba musí být rychlejší. (pozn: máme cca 700 tabulek, k tomu odpovídající Hibernate entity, které se musí vždy všechny inicializovat. Dokončení modularizace aplikace s možností vypnutí/zapnutí modulů bude až tak příští rok). Zde by možná mohl pomoci systém agentů, který znám z TeamCity. Nebo vhodně definovat testovací profily a pouštět to na více strojích vždy pouze s daným profilem.


18. září 2011

Proč nechci použít Hibernate na dalším projektu

Minulý týden se mě kolega zeptal, zda bych použil znovu Hibernate na dalším projektu? Já jsem mu po krátkém zamyšlení řekl, že již ne, že bych Hibernate (a obecně žádné jiné ORM řešení) nepoužil. Následovala diskuze, kde jsem se snažil obhájit mojí odpověď:

  • ORM nástroje se snaží vývojáře odstínit od konkrétního úložiště dat, snaží se vývojáře držet pouze v objektovém světě bez ohledu na to, že nejčastěji ukládáme data do relačních databází. Je naivní si myslet, že napíši kvalitní aplikaci bez znalostí databází a SQL.

  • ORM nástroje (pozn. konkrétně Hibernate, protože s ním několik let pracuji, ale myslím si, že to lze zobecnit pro všechny ORM nástroje) přidávají do projektů další velkou složitost, nároky na znalosti a zkušenosti. Toto má vliv na spoustu dalších věcí - výběr vhodných lidí do týmu, architektura systému, větší pravděpodobnost chyb, plnění termínů atd.

  • znalost SQL mi přijde natolik rozšířená a základní, že v tomto nevidím další znalostí zátěž pro vývojáře

  • používání ORM odstiňuje vývojáře od přímé práce s databází, což často vede k tomu, že vývojáři vůbec vlastně nevědí, jak jsou určité operace náročné, kolik se vlastně výsledně musí zavolat SQL dotazů, aby se jedna Hibernate operace vykonala

  • Hibernate přináší do vývojového týmu prvek náhodnosti, špatné říditelnosti - pokud vím, že mám napsat 3 dotazy přes JDBC, tak je to tak jasná a ohraničená věc, že není co dalšího řešit. Místo toho implementovat DAO pomocí Hibernatu, to moc jasné být nemusí - nikdy člověk neví, na čem se může zaseknout nebo jak se bude Hibernate v určitých kritických stavech chovat.

  • při porovnávání JDBC vs. ORM přístupů je potřeba také zmínit, že databáze často mnohonásobně přežijí aplikace, které je využívají. Technologie pro server a klienta se mění mnohem rychleji než relační databáze a jazyk SQL. Z tohoto pohledu je základem správný návrh databáze bez ohledu na to, jakou architekturu pak aplikace bude mít.

  • kolikrát se na projektu měnila databáze? Možná lepší otázka - stalo se již někomu, že se během projektu měnila databáze? Když pominu vývoj aplikací pro více databází, tak naopak si myslím, že napojení na konkrétní databázi mi nabízí mnohem více než když jsem odstíněný přes ORM.

  • ladění složitějších HQL nebo Criteria dotazů moc nejde a já osobně jsem vždy skončil u SQL. Někdy postupuji i naopak - pomocí SQL si vyzkouším, že daný dotaz je možné vytvořit, a že je správný a pak ho přepisuji pomocí Hibernatu.

Myslím, že nejsem sám, kdo má dnes podobný názor k této problematice jako já, viz např. článek Problems with ORMs jako jeden z nich.

Základní otázkou ale zůstává, co tedy jiného místo toho? Mě zde bohužel chybí osobní zkušenost, ale určitě bych se vydal cestou přes JDBC, tedy jako vhodné řešení mi přijde použití MyBatis nebo Spring JDBC nebo Spring Data nebo to celé nějak zkombinovat dohromady.