Předevčírem jsem na JUG Ostrava mluvil o unit testech a test-driven vývoji. Na rozdíl od WebExpa jsme měli víc času, a tak jsem se dostal i k tomu, proč nejsou unit testy dobré k odhalování chyb, co vám unit testy říkají o testovaném kódu a v čem je jejich nejsilnější stránka.
Záznam z přednášky už je na webu (děkuji Ondrovi Kvasnovskému za bleskové zpracování). Pokud jste viděli moji přednášku na WebExpu, přetočte na čas 26:40, kde začíná druhá část, na kterou se na WebExpu nedostalo.
Odkazy k přednášce najdete v mém předchozím postu. Na závěr jsem v diskuzi zmiňoval toto video od Kenta Becka, ve kterém vysvětluje, jak dělat velké změny po malých a bezpečných krocích.
V přenášce jsem zapomněl zmínit jednu věc. Pokud píšete unit testy zpětně, tedy až když máte hotový kód, přicházíte o tu největší srandu. Přínosy unit testů se nejvíc projeví právě když jste test-driven, čili píšete nejdřív testy, pak kód. Já jsem stále víc přesvědčen o tom, že psát unit testy zpětně je zbytečné a že lidé, kteří tak programují, hledají u unit testů něco, co jim nemůžou poskytnout. Pokud si myslíte že to nejde nebo že to neumíte, tak trénujte! Nikdo učený z nebe nespadl a stojí za to se to naučit.
Test Driven Development - Outside-in, Daniel Kolman from Java User Group - Ostrava on Vimeo.
Nekdy duvod proc lide pisi testy je vice prozaicky. Napriklad podminku mergnuti kodu muze byt unitovy test jako dukaz funkcnosti kodu. A samozrejme testovat kod jenom rozbehnutim aplikace muze byt zdlouhavy. Takze prestoze vysledny test neni mnohdy efektivni a byva tezko udrzovatelny je bohuzel nekdy nutne zlo.
OdpovědětVymazatPokud má být test důkazem, že něco funguje, pak to může být stěží unit test. Ještě jsem neviděl requirement/feature request/user story (říkejme tomu jakkoliv) který by požadoval něco na úrovni třídy. Zadání od business lidí se vždy týká externí kvality, a pokud se snažíme něco takového dokázat unit testem, stavíme Potěmkinovu vesnici. Ale jinak chápu že v "entrprajsu" je možný úplně všechno:)
OdpovědětVymazatV TDD by Example Kent doporučuje implementaci testu odzadu tj. začít od Assertu a končit Arrangem. To, že máš třídu Game, zjistíš jako poslední, neurčíš to jako první. Ale to jen takové malé doplnění k tomu, co jsem zatím viděl. Moc se mi toho do autobusu nabufferovat nepodařilo. :)
OdpovědětVymazatZatim se mi to líbí, ale nerad bych hodnotil než to zkouknu celý. :D
Muj komentar se tykal hlavne jiz existujiciho kodu. Takze zmeny, ktere jsou vynuceny napr. bug reportem, nebo change request. Samozrejme, ze externi kvalitu unit testem neprokazes, ale stakeholdri cim dal casteji slepe vyzaduji test coverage na urcite urovni, protoze to pro ne znamena cislo :-). A jako takove se da sledovat v case.
OdpovědětVymazatSamozrejme i v tomto pripade plati, ze dlouhy test ukazuje na problemy v designu, ale ne vzdy si muzes z casovych duvodu dovolit kod refaktorovat, idkyz by si i chtel :-).
Řekl bych, že ten první test není úplně ideální - v podstatě kontroluje vnitřní implementaci!
OdpovědětVymazatMísto testování jestli byla zavolána metoda na boardu by game měla mít metodu getToken, kterou si ověříme, že token je na dané pozici.
Tímto způsobem se vnitřní implementace třídy Game může změnit bez toho aby bylo třeba měnit test.
@Unknown: No právě, unit test nám umožňuje testovat chování objektu bez různých berliček get-metod. Pokud se na test díváme jako na prostředek návrhu objektů a jejich interakcí, chování je součástí kontraktu a nelze ho měnit bez změny testu.
OdpovědětVymazatViz také rozdíl mezi state-based a behavior-based verification: http://martinfowler.com/articles/mocksArentStubs.html#ClassicalAndMockistTesting