Comments on: Unit testy a čistota návrhu http://blog.krecan.net/2007/06/14/unit-testy-a-cistota-navrhu/ Short remarks from Java world Wed, 07 Jan 2009 02:26:23 +0000 http://wordpress.org/?v=2.7 hourly 1 By: Honza Novotný http://blog.krecan.net/2007/06/14/unit-testy-a-cistota-navrhu/comment-page-1/#comment-270 Honza Novotný Sun, 02 Sep 2007 20:19:31 +0000 http://blog.krecan.net/2007/06/14/unit-testy-a-cistota-navrhu/#comment-270 Já jsem se naopak přistihl, že v podstatě velmi málo programuji unit testy. Obvykle se jedná o testy integrační. Velmi často jsou zodpovědnosti tříd tak malé, že by ten test v podstatě nic moc neotestoval. Teprve složením více tříd dohromady vzniká nějak rozumě funkční celek. Typicky tedy dělám testy, které testují spolupráci dvou tří tříd. Mocky mi potom izolují tyto kooperující třídy od zbytku světa - a přestože refakturuji docela dost, nepřipadá mi, že by mi mocky nějak výrazně stěžovaly práci. Nicméně pravda je, že to s mocky taky extra nepřeháním ;). Zajímalo by mě Petře, co myslíš tím, že nepoužíváte TDD. Znamená to, že nedodržujete pravidlo "Test first" nebo to, že odladíte aplikaci a teprve v závěru píšete testy? Pokud to první, tak jsme na tom stejně. Zatím jsem nedospěl k tomu nejdřív psát testy. Obvykle nejdříve napíšu kód a pak test. Přičemž k odladění kódu právě používám test (testy). Defakto kód + test vzniká současně. Pokud bych psal test jako první, musel bych ho dost šíleně přepisovat, protože psaní vlastního kódu je u mě dost živelné. To co vypadá, že na začátku by mohla dělat jedna třída, v závěru dělají třeba třídy tři atd. Před dvěma, tři lety jsem psal testy až když byla aplikace celá hotová - sloužily mě jen k zafixování status quo. Což považuji ze současného pohldu za pěknou pitomost. Jednak jsem musel před manažery obhajovat čas strávený nad psaním testů (prostě to bylo "strašně vidět" - přitom žádná funkčnost už nepřibývala) a jednak jsem si neušetřil žádnou práci. Pokud se ale píšou testy současně, průběžně vzniká funkcionalita s testy a psát testy je i zábavnější. Navíc se tím děsně šetří čas, protože si člověk odladí většinu aplikace jen v prostředí IDE - navíc je daleko jednoduší testovat aplikaci po menších částech než jako celek s opakovanými deploymenty na server. Mám ten pocit (neověřený), že v současné době píšu výsledný kód i testy rychleji, než kdybych vyvíjel jen samotnou aplikaci s neustálými deploymenty + ručním ověřováním a laděním chování této aplikace. Samozřejmě významnou měrou k tomu přispívá i Spring - ten člověka jednak vede k lepšímu rozpadu funkčnosti a navíc má skělou podporu pro testování. Já jsem se naopak přistihl, že v podstatě velmi málo programuji unit testy. Obvykle se jedná o testy integrační. Velmi často jsou zodpovědnosti tříd tak malé, že by ten test v podstatě nic moc neotestoval. Teprve složením více tříd dohromady vzniká nějak rozumě funkční celek. Typicky tedy dělám testy, které testují spolupráci dvou tří tříd. Mocky mi potom izolují tyto kooperující třídy od zbytku světa - a přestože refakturuji docela dost, nepřipadá mi, že by mi mocky nějak výrazně stěžovaly práci. Nicméně pravda je, že to s mocky taky extra nepřeháním ;).

Zajímalo by mě Petře, co myslíš tím, že nepoužíváte TDD. Znamená to, že nedodržujete pravidlo “Test first” nebo to, že odladíte aplikaci a teprve v závěru píšete testy?

Pokud to první, tak jsme na tom stejně. Zatím jsem nedospěl k tomu nejdřív psát testy. Obvykle nejdříve napíšu kód a pak test. Přičemž k odladění kódu právě používám test (testy). Defakto kód + test vzniká současně. Pokud bych psal test jako první, musel bych ho dost šíleně přepisovat, protože psaní vlastního kódu je u mě dost živelné. To co vypadá, že na začátku by mohla dělat jedna třída, v závěru dělají třeba třídy tři atd.

Před dvěma, tři lety jsem psal testy až když byla aplikace celá hotová - sloužily mě jen k zafixování status quo. Což považuji ze současného pohldu za pěknou pitomost. Jednak jsem musel před manažery obhajovat čas strávený nad psaním testů (prostě to bylo “strašně vidět” - přitom žádná funkčnost už nepřibývala) a jednak jsem si neušetřil žádnou práci. Pokud se ale píšou testy současně, průběžně vzniká funkcionalita s testy a psát testy je i zábavnější. Navíc se tím děsně šetří čas, protože si člověk odladí většinu aplikace jen v prostředí IDE - navíc je daleko jednoduší testovat aplikaci po menších částech než jako celek s opakovanými deploymenty na server.

Mám ten pocit (neověřený), že v současné době píšu výsledný kód i testy rychleji, než kdybych vyvíjel jen samotnou aplikaci s neustálými deploymenty + ručním ověřováním a laděním chování této aplikace. Samozřejmě významnou měrou k tomu přispívá i Spring - ten člověka jednak vede k lepšímu rozpadu funkčnosti a navíc má skělou podporu pro testování.

]]> By: Petr Jůza http://blog.krecan.net/2007/06/14/unit-testy-a-cistota-navrhu/comment-page-1/#comment-124 Petr Jůza Mon, 18 Jun 2007 11:39:09 +0000 http://blog.krecan.net/2007/06/14/unit-testy-a-cistota-navrhu/#comment-124 Naprosto s tebou souhlasim, ze na testech se hodne dobre pozna, zda produkcni kod je dobre navrzen. S tim (snad) problemy nemam, ale me proste vadi, ze je narovne ty mock testy behem vyvoje udrzovat a to ani nemluvim o tom, kolik moznych kombinaci je nutne prokryt v urcitych pripadech. Z toho prameni moje pochybnosti, zda ten cas venovany psani mock testu je pro me takovym prinosem. Naprosto s tebou souhlasim, ze na testech se hodne dobre pozna, zda produkcni kod je dobre navrzen. S tim (snad) problemy nemam, ale me proste vadi, ze je narovne ty mock testy behem vyvoje udrzovat a to ani nemluvim o tom, kolik moznych kombinaci je nutne prokryt v urcitych pripadech. Z toho prameni moje pochybnosti, zda ten cas venovany psani mock testu je pro me takovym prinosem.

]]> By: Lukáš Křečan http://blog.krecan.net/2007/06/14/unit-testy-a-cistota-navrhu/comment-page-1/#comment-123 Lukáš Křečan Mon, 18 Jun 2007 07:13:11 +0000 http://blog.krecan.net/2007/06/14/unit-testy-a-cistota-navrhu/#comment-123 Já používám EasyMock s kterým jsem spokojen. A mám takovou zkušenost, že když se něco špatně testuje, tak je to špatně navrženo. Neplatí to vždy, ale často je to dobrý indikátor příliš úzké vazby mezi třídami nebo toho, že jedna třída toho dělá víc než by měla. Já používám EasyMock s kterým jsem spokojen. A mám takovou zkušenost, že když se něco špatně testuje, tak je to špatně navrženo. Neplatí to vždy, ale často je to dobrý indikátor příliš úzké vazby mezi třídami nebo toho, že jedna třída toho dělá víc než by měla.

]]> By: Petr Jůza http://blog.krecan.net/2007/06/14/unit-testy-a-cistota-navrhu/comment-page-1/#comment-122 Petr Jůza Mon, 18 Jun 2007 06:49:50 +0000 http://blog.krecan.net/2007/06/14/unit-testy-a-cistota-navrhu/#comment-122 Co se týká Mock testování, tak se musím přiznat, že pořád si nejsem 100% jistý, že ten čas věnovaný Mock testů byl dobře využitý. Co tím mám na mysli? Mock testy mi přijdou celkem náročné na údržbu - během vývoje se určité věci celkem mění, navíc používám JMock, kde se zapisuje jméno metody pomocí řetězce, takže zde není možné použít refactoring. To samo o sobě mi ještě tak nevadí, kdybych ovšem viděl pořadný přínos těchto testů. Jako jedinou hmatatelnou výhodu vidím v tom, že mi ty Mock testy udržují správné hranice uvnitř systému. Jinak řečeno díky těm testům se mohu spolehnout, že jiní členové týmu mi tam něco nezměnili, že to pořád funguje stejně jak má. A zde si právě nejsem jistý, zda to není málo za ten čas strávený psaním těchto testů, zda by nebylo lepší tento čas investovat do jiných typů testů, např. testování GUI? Jen pro info: vyvijíme v rámci 2-3 členého týmu, nepoužíváme TDD, testy píšeme na úrovni rozhraních (mezi jednotlivými vrstvami aplikace) a pak funkční testy dle potřeby. Co se týká Mock testování, tak se musím přiznat, že pořád si nejsem 100% jistý, že ten čas věnovaný Mock testů byl dobře využitý.

Co tím mám na mysli? Mock testy mi přijdou celkem náročné na údržbu - během vývoje se určité věci celkem mění, navíc používám JMock, kde se zapisuje jméno metody pomocí řetězce, takže zde není možné použít refactoring.
To samo o sobě mi ještě tak nevadí, kdybych ovšem viděl pořadný přínos těchto testů. Jako jedinou hmatatelnou výhodu vidím v tom, že mi ty Mock testy udržují správné hranice uvnitř systému. Jinak řečeno díky těm testům se mohu spolehnout, že jiní členové týmu mi tam něco nezměnili, že to pořád funguje stejně jak má.
A zde si právě nejsem jistý, zda to není málo za ten čas strávený psaním těchto testů, zda by nebylo lepší tento čas investovat do jiných typů testů, např. testování GUI?

Jen pro info: vyvijíme v rámci 2-3 členého týmu, nepoužíváme TDD, testy píšeme na úrovni rozhraních (mezi jednotlivými vrstvami aplikace) a pak funkční testy dle potřeby.

]]> By: Honza Novotný http://blog.krecan.net/2007/06/14/unit-testy-a-cistota-navrhu/comment-page-1/#comment-121 Honza Novotný Fri, 15 Jun 2007 09:50:49 +0000 http://blog.krecan.net/2007/06/14/unit-testy-a-cistota-navrhu/#comment-121 Zlatá pravda - testy se vyplatí i jen ve chvíli kdy se kód vyvíjí - už v tom momentě začínají pomáhat čistit návrh. A druhá zlatá pravda - s mocky se to nedá přehánět, jsou sice řádově mnohonásobně rychlejší, ale nejsou tak spolehlivé jako integrační testy. Na druhou stranu nejsou tak náchylné na změny. No prostě jak říká Testuvius "Sometimes your thirst is best quenched by beer and your hunger by buffallo wings." Zlatá pravda - testy se vyplatí i jen ve chvíli kdy se kód vyvíjí - už v tom momentě začínají pomáhat čistit návrh. A druhá zlatá pravda - s mocky se to nedá přehánět, jsou sice řádově mnohonásobně rychlejší, ale nejsou tak spolehlivé jako integrační testy. Na druhou stranu nejsou tak náchylné na změny. No prostě jak říká Testuvius “Sometimes your thirst is best quenched by beer and your hunger by buffallo wings.”

]]>