http://www.boruvka.net/blog/2007/07/eclipse-nefunkn-hot-code-replace.html

BTW: o modulech jsem přeci nemluvil ne?!

Varoval bych se přeceňování mock testování. jak odhalíte např. chybu sestaveného projektu? Celek přeci není jen součet částí - části mohou samostatně fungovat jak víno, ale po sestavení tam mohou být třecí plochy, které způsobí, že to nakonec jako celek nefunguje.

Typicky např. když v mock objektech pracujete jen se svými “vymyšlenými” daty. Nakonec si zkusíte udělat integrační test nad reálnými daty v DB, na úrovni business vrstvy a klidně zjistíte, jak vám to hezky padne na hubu, jenom proto, že jste ve svých mock objektech vždy vracel konkrétní “ozkoušená” testovací data, se kterými business objekty počítaly. S reálnými daty, ale mohou klidně vyhořet. A není to tím, že byste něco podcenil, nebo špatně programoval - prostě se jen nedá vždy 100% počítat se všemi variantami. Tohle vím, protože jsem si to ozkoušel na vlastní kůži - od té doby integrační testy nepodceňuji.

Spíš je otázka, kde leží ten správný poměr mezi testy.

Možná, když pracuje člověk na projektu sám, tak se dá tento problém minimalizovat (a záleží na velikosti projektu). Ale stejně bych integrační testy, jdoucí napříč aplikací nepodceňoval. Nemusí být složité - správná funkcionalita je zajištěna unit testy - ale často odhalí, že při konkrétním použití (v kombinaci) se generují chyby.

Takze ne, nedelam integracni test nikde jinde, nez tam kde neuspeju s mockem. A s mockem jsem zatim neuspel, jenom na urovni databaze. (btw. dao objeckt pro potreby trid normalne mockuju, ale pri testovani samotne implementace dao objektu, je potreba testovat jej proti databazi).

Shodneme se určitě na tom, že záleží na konkrétní situaci. S tímto bych to tedy asi uzavřel ;).

Btw. integracni test, je myslim, jenom pro DAO. Btw. GUI jsem se jeste testovat nenaucil, takze to testuji skutecne rucne :(. Myslim, ze by se situace vyrazne zmenila, kdybych nepouzival spring a aplikaci spoustel v kontejneru. to by pak integracni testovani vyzadovalo kde co.

Zkuste se zamyslet nad tim, jestli delate dobre kdyz vase metody maji vice nez jednu funkci. Resp. kdyz mam metodu od ktere povazuji dve funkce, tak to provedu tak ze zavolam dve metody, ktere maji vzdy jednu funkci. Tim si vyrazne zjednodusite praci jak s testama, tak s pripadnym prepisovanim testu.

Btw. jde urcite o typ aplikace, kteoru vytvarite. Delate-li aplikaci jen pro jednoho zakaznika, muzete si dovolit chybu, protoze kdyz se na chybu narazi opravite ji a velmi snadno dostanete k zakaznikovi. Kdyz ale mate zakazniku spousty, tak Vam oprava chyby zabere spoustu casu. A to nejvic na zvedani telefonu, protoze ti zakaznici pouzivaji ve stejnem obdovi stejnou funkci a tudiz vsichni vam volaji v jednu chvili. Z toho spousta z nich zvladne vypnout automatickou aktualizaci, ale uz nezvladne jednosduse pravidelne aktualizovat :).

Takze jak rikam, jde o to jakou aplikaci vyvyjite a jake prostredky jste nucen pouzit.

Pravda je, že si myslím, že ladění kódu pomocí “asynchroně” pomocí logovacích záznamů v čase vývoje se mi zdá jako neefektivní. Nicméně, každý z nás je originál - a je klidně možné, že vy s pomoců logů hledáte chyby rychleji než já s pomocí debuggeru. Co jsem však v praxi poznal byl naprostý opak - minutové analyzování dlouhých debug logů tam, kde mě s debuggerem stačí 15 - 30 vteřin. Nutnost redeploye (restartu serveru) tam, kde mne stačí překompilování třídy a HOT REDEPLOY. To co se snažím v článku obhajovat je pouze efektivita vývoje na úrovni, kterou může ovlivnit každý programátor. Opravdu to neberte jako zpochybňování vašich zvyků vývoje, v podstatě se hlavně jedná o moji zkušenost.

Další skvělá vlastnost debuggeru, kterou logy těžko efektivně nahradíte je ad hoc vyhodnocování Java výrazů za běhu, v kontextu běžící aplikace.

Co se týká průzkumu cizího kódu - souhlasím a také to praktikuji. Je opravdu rozdíl, traverzovat kódem místo snažení se naslepo otestovat a pochopit black box. Tady už to kolikrát neznamená jen ztrátu času - ale rozdíl mezi proniknutím do logiky nebo ne. Mmch. např. z Acegi Security jsem se hodně naučil o Springu a je tam i zajímavá dekompozice systému k okouknutí. To zvenku prostě nepoznáte. Někdy je však problém donutit IDE aby vám ve zdrojácích cizích tříd (připojených jako JARy) procházelo - v IntelliJ Idea se mi to zdá asi nejjednoduší k rozchození. V Netbeans jsem měl svého času problémy nastavit breakpointy - muselo se to nastavovat jako v otevřeném class a nikoliv v samotném source file (mám ten dojem, že když si tam dáte GoTo Class a dáte název cizí třídy - zobrazí se vám 2x - jednou jako source a jednou jako class, ať vyberete cokoliv, otevře se source, ale breakpointy fungují jen když vyberete class). V Eclipsu jsem se nějak beznadějně ztratil … ale tam se mi to stávalo pořád.

Ad testování a refaktoring: Tady jde asi především o styl vývoje. Například já o sobě vím, že programovat pomocí UML diagramů (a jsou lidé, kterým tento styl vývoje vyhovuje, jinak by nevzniklo MDA) není pro mne. Class diagramy sice v pohodě nakreslím, ale nemyslí mi to v nich - v kódu obvykle zjistím, že existuje elegantnější řešení a původní představu třebas dvakrát překopu než jsem spokojen (mluvím o složitějších částech aplikace - na jednoúčelových metodách není co vymýšlet - jde spíš o dekompozici a výsledné poskládání “jednoúčelových metod”). Faktem je, že při tomto stylu vývoje na začátku přesně nevím, jak bude vypadat výsledné řešení, takže na konci je z původních třech tříd, tříd deset - v metodách klidně polovina parametrů ubyde, protože úkoly převzala jiná metoda volaná mimo tuto metodu atd. atd.

Po přečtení knihy Extrémní programování od Kenta Becka jsem taky psal nejdřív testy, ale po nějaké době jsem toho nechal, protože jsem byl dost neefektivní. Prostě jsem strávil plno času přepisováním testů. Je jasné, že pokud se jen metoda přesunuje není problém - horší je, jakmile se vám mění kontrakt metody - najednou část toho co dělala původní metoda, dělají třebas dvě metody jiných tříd. Pak se třebas logika přípravy prostředí pro test dost špatně přenáší - rozhodně ale do testu už musíte sáhnout.

Dost v tomhle mohou pomoci mock objekty, které kladou minimální nároky na přípravu okolního prostředí - v podstatě si ho můžete celé nasimulovat a pak už ty náklady se změnamy už nejsou tak veliké. Ale s pomocí mock objektů se také nedá testovat všechno (stejně musíte mít nějaké integrační testy).

Buďto tedy něco dělám zásadně špatně (doufám že ne), nebo je to zase jen důsledek toho, že jsme každý jiný, a každý má tak trochu ten svůj osobitý styl vývoje.

A zmenim tridu. Pak zu jenom Tam kde se to jevi vhodne soupnu LOGGER.debug. V log4j.properties mam udelane loggery pro kazdy balik zvlast. Takze mam nekolik log souboru a tri hlavni (textovy, na konzoli a html). Hlasky mam rozsypane po ruznych mistech.

K debugingu musim sahnout kdyz dojde k chybe, tam kde jsem ji necekal. Necekal jsem chybu jenom tam kde nejsou testy. Dejde-li k chybnemu chovani, dochazi k nemu v nejake metode, naprosto vzdy se da pouhou uvahu urcit ktera metoda to spousti. Takze do testu nasadim data, ktera tvorila chybu a projedu testy. Okamzite vidim, kde dochazi k chybam. A co chcete v deseti radkove metode debuggerovat?

Jak rikam, obcas k nemu sahnu, vetsinou, ale jenom tehdy, kdyz se framework (spring nebo hivernate), nechova tak jak jsem cekal a nechce semi psat testy frameworku. Takze tak jak rika filemon na pochopeni ciziho kodu.

Honza Novotný: Co refaktorujete na jednoucelove metode? Presouvate ji do jine tridi? No pak musite presunout i test. Menite nekdy chovani jednoucelovych metod? U mne se to stava jen zridka, spis proste nektere metody se stanou deprecated, ale proto nemusism jeste prepisovat testy. Takze u mne se stava jenom ze proste test smazu, protoze jsem smazal metodu. Neuvedomuji si, ze bych nekdy menil chovani testu, protoze jsem zmenil chovani metody. To se mi snad jeste nestalo. Proste metoda ma jmeno, ktere v podstate urcuje co dela, jeden dva parametry, nejaky vystup a slus. Kdyz ji nepotrebuju smazu ji a napisu metodu novou. Je-li chybna, oprvim ji. Je umistena ve spatne tride? Presunu ji i prislusny test. Tot vse.

Další věcí je, že píšu testy obvykle pouze na úrovni business vrstvy a to většinou testy integrační - tedy včetně propojení na vrstvu datovou. Po zkušenostech s testováním webové vsrstvy jsem zanechal psaní testů pro ni, jelikož se musely neustále opravovat a ten efekt jsem nějak neviděl. Webovou vrstvu tedy ladím přímo klikáním, a tam se mi HOT REDEPLOY opravdu hodně hodí - šetří plno času v kolečkách: nalezení chyby, oprava, deployment, otestování. Ve výsledku mám tedy obvykle vyladěnou business vrstvu pomocí testů a pouze GUI ladím tím “starým” ručním způsobem.

Souhlasím s Brdloushem, že debugger je skvělá věc, kterou řada jazyků prostě nemá. Tento článek měl právě vést k zamyšlení, jestli skutečně využíváme těch výhod, které nám Java nabízí. Leta jsem vyvíjel v prostředí, kde jsem debugger nemohl použít a tam opravdu nezbývalo než se spolehnout na logování - taky to jde, ale efektivita je prostě někde jinde. Jak jsem psal - ve většině případů vám debugging ušetří enormní množství času - a to i v případě, že vyvíjíte pomocí testů - vždyť přeci i při spuštění testů si můžete dát breakpoint (já používám IntelliJ IDEA a ta podpora to toto je naprosto úžasná) a přijdete na problém mnohem dřív.