Administrace komentářů

Nejlepší definice unit testu, kterou jsem kdy četl, zní (přibližně): unit test je test, který doběhne do 0,1 vteřiny a ukáže přesně na místo, kde je problém. Tohle rozdělení na jednotkové testy, integrační testy a čert ví jaké testy nedává pro začátečníky žádný smysl, zvlášť když se píšou úplně stejně a s pomocí stejných nástrojů.

Pro tazatele: Asi nejlepší knížka o testování, kterou jsem četl (i když jsem jich moc nečetl), nemá vůbec testování v názvu (Working Effectively with Legacy Code, vyšlo i v češtině, zběžně jsem prolítl a překlad se mi nezdál špatný), i když o ničem jiném než testování není. Nejsem si jistý, ale ta definice unit testu výše myslím pochází z téhle knížky.

Ale spíš než čtení bych doporučil: Drapněte nějaký testovací framework a zkuste napsat test, který něco ověří. Nemusí ověřit hned všechno, podstatné je, abyste zjistil, že na tom nic není. Až tohle zjistíte, začnete přemýšlet, jak strukturovat kód tak, aby byl testovatelný (a Working Effectively with Legacy Code je celá o tom, jak z netestovaného a netestovatelného kódu udělat testovatelný a testovaný). Ledacos mimochodem zvládnou vyřešit mockovací frameworky. (Příklad z Javy: potřebujete otestovat chování metody, která se řídí podle nějaké systémové proměnné čtené přes System.getProperty? Okay, tu metodu nemusíte vůbec měnit, můžete si nadiktovat posloupnost návratových hodnot té metody System.getProperty a nechat bajtkódovou magii mockovacího frameworku, ať se postará.)

Pokud používáte Javu, můžu doporučit kombinaci JUnit+Mockito+PowerMock, pokud Céčko, dobře vypadá Cmockery od Googlu (ale nezkoušel jsem), pokud něco jiného, možná poradí někdo jiný.

Až to zmáknete, tak časem zjistíte, že by bylo dobré pouštět testy automaticky při každém commitu do repozitáře a nainstalujete si nějaký continuous integration server (z javovského světa můžu doporučit TeamCity, které je do určitého omezení zdarma, ale není open-source, příp. je docela oblíbený Hudson, jehož nekorporátní verze se teď kvůli nějakým rozmíškám v Oraclu jmenuje Jenkins; Céčkaři tuším používají Buildbot, ale neznám).

Ještě později zjistíte, že některé testy běží výrazně pomaleji než jiné (typicky ty, které sahají na disk nebo do databáze, komunikují přes síť apod.) a že by nebyl špatný nápad pouštět je méně často, třeba v noci. Takové testy přesunete do vedlejšího adresáře, nazvete je integrační testy, a to, co zůstane v původním adresáři, budou unit testy. Gratuluju, jste na vyšším levelu a můžete poučovat začátečníky, jako jste byl sám. Konec dobrý, všechno dobré.

Poznámka pro odborněji zaměřené: V textu výše jsem úplně ignoroval "mimofunkční" testy (nevím, jak to líp nazvat, možná "testy mimofunkčních požadavků"?), a to prostě proto, že by to byl ještě další rozměr bordelu navíc.