abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 11:44 | Zajímavý projekt

Na Indiegogo byla spuštěna kampaň na podporu herní mini konzole a multimediálního centra RetroEngine Sigma od Doyodo. Předobjednat ji lze již od 49 dolarů. Požadovaná částka 20 000 dolarů byla překonána již 6 krát. Majitelé mini konzole si budou moci zahrát hry pro Atari VCS 2600, Sega Genesis nebo NES. Předinstalováno bude multimediální centrum Kodi.

Ladislav Hagara | Komentářů: 0
dnes 00:10 | Nová verze

Byla vydána verze 4.7 redakčního systému WordPress. Kódové označením Vaughan bylo vybráno na počest americké jazzové zpěvačky Sarah "Sassy" Vaughan. Z novinek lze zmínit například novou výchozí šablonu Twenty Seventeen, náhledy pdf souborů nebo WordPress REST API.

Ladislav Hagara | Komentářů: 0
včera 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 14
včera 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

Ladislav Hagara | Komentářů: 1
5.12. 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 6
5.12. 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 50
5.12. 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 10
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 17
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 26
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 779 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Unit Tests

12.2.2011 17:07 Mira
Unit Tests
Přečteno: 2051×
Ahoj,

doporucte mi prosim dobrou knihu nebo tutorial o Unit Testing. Nejlepe takovou, ktera obsahuje i prakticke priklady.

Myslim si, ze principu Unit Testu v zasade rozumim. Horsi uz to je, kdyz mam testy pro svuj kod skutecne psat.

Mnoho mych trid totiz provadi relativne slozite a spatne kontrolovatelne akce - napriklad vytvari soubory na disku, meni jejich obah. Nedovedu si predstavit, jak pro takove operace psat unit testy (resp. sepsat takovy test by myslim bylo velmi velmi pracne).

Potreboval bych ziskat praktickou predstavu, kdy je vyhodne pro tridu test psat a jak jej nejlepe vytvorit.

Predem dekuju, Mira

Odpovědi

12.2.2011 17:41 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Unit Tests
Pokud třída provádí složité akce, je to kandidát na testování jiným způsobem, než unit testy – unit testy mají testovat jednotky, jednotlivé akce.
12.2.2011 19:44 Mira
Rozbalit Rozbalit vše Re: Unit Tests
Jake testovani by to mohlo byt? Myslim pokud mozno nejakou formu automatickych test.
12.2.2011 20:07 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Unit Tests
Když se budu řídit tím, jaké druhy testování rozlišuje Wikipedie, bylo by to asi System testing. Ale ony se ty další názvy (mimo unit testing) pokud vím moc nepoužívají, a ani pro to není moc podpora v podobě existujících nástrojů. Když už se to nějak pojmenovává, tak se spíš všemu nad unit testy říká integrační testy.

Většinou se to řeší různými nadstavbami nad nástroji pro unit testing. Podle mne zatím nepanuje ani shoda na tom, zda vůbec automatizované testy nad unit testy dělat, natož aby k tomu byla nějaká doporučení nebo dokonce nástroje. Trochu o tom píše Roman Pichlík v Co mě testy naučily o mém kódu. Já sice souhlasím, že u správného objektového kódu se toho unit testy dá otestovat hodně, ale často není potřeba a hlavně ani čas jít na takovou úroveň abstrakce.
12.2.2011 20:19 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Unit Tests
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.
Ještě na tom nejsem tak špatně, abych četl Viewegha.
12.2.2011 20:21 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Unit Tests
Jo, a kdy je vyhodne pro tridu test psat? Na to je snadná odpověď. Vždycky.
Ještě na tom nejsem tak špatně, abych četl Viewegha.
13.2.2011 09:47 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Unit Tests
Popisujete běžnou praxi, která se používá, aby si vývojáři mohli odškrtnout „používáme automatizované testy“. Takovéhle testy ale nic moc netestují, akorát zaměstnávají vývojáře opravami testů, případně jejich zakomentováním. Tazatel se ale ptal na literaturu, takže jsem předpokládal, že se chce dozvědět o takovém testování, které k něčemu bude.

Testování má kontrolovat výsledek nějaké operace, ne její postup. Když ten postup napíšete špatně do kódu, napíšete jej nejspíš špatně i do testu. Když budete nějaký postup optimalizovat, ale má dávat stejný výsledek, musíte změnit i test – přitom ten měl právě zůstat stejný a kontrolovat, zda kód před změnou i po změně dává stejné výsledky.

Pokud můžete kód vystavět tak, aby se jeho velká část dala testovat skutečnými jednotkovými testy (které nepotřebují mocking, změny bajtkódu apod.), máte vyhráno. Pokud vás něco nutí napsat špagetový kód, napište si testy alespoň pro nějaké kritické funkce nebo takové, kde často dochází k chybám. Je potřeba ale počítat s tím, že takový kód se špatně udržuje (i špatně testuje). Energii bych v takovém případě věnoval spíš zlepšení toho kódu a přepisu na objektový kód, psaní špatných testů pro špatný kód podle mne přinese mnohem menší užitek.
13.2.2011 12:38 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Unit Tests
Nejsem si jistý, co jste se svými pověstnými interpretačními schopnostmi z mého příspěvku vyčetl, ale jestli jsem v něm chtěl popsat nějakou praxi, pak asi takovou: Jakýkoli test je lepší než žádný test, za čímž si stojím a je mi fuk, jestli s tím třeba nesouhlasíte. Jestli máte na mysli tu závorku s příkladem na System.getProperty, tak to byl extrémní příklad. Ale ani ten se nezabývá postupem, ale prostě to je whitebox test. So what? S dependency injection (i pro takové věci jako právě systémové proměnné) a rozhraními všude je to jednodušší a nemusí se tolik sahat k těm whiteboxům, ale holt nežijeme v ideálním světě.

Takže, abychom si rozuměli. V prvním odstavci podávám užitečnou definici unit testu (ne svoji). Ve druhém odstavci upozorňuju na existenci knížky Working Effectively with Legacy Code. Ve třetím odstavci tvrdím, že namísto dlouhého studia je lepší se do toho vrhnout po hlavě, že člověk velmi brzo začne přemýšlet, jak strukturovat kód tak, aby byl testovatelný, a že s ledasčím mohou pomoci mockovací frameworky. Ve čtvrtém odstavci odkazuju na pár knihoven pro testování, v pátém odstavci zmiňuju CI a odkazuju na pár nástrojů, v šestém odstavci dělám čáru mezi unit testy a integračními testy na tom místě, kde se obvykle dělá. V sedmém odstavci zmiňuju, že jsem vůbec nezmiňoval testy mimofunkčních požadavků. V žádném odstavci nezmiňuju testy, které ověřují postup operací namísto jejich výsledku (i když i to může být někdy užitečné).

Poznámka k vašemu poslednímu odstavci: Ke špatnému kódu je klíčové napsat testy ještě před jeho přepisem, protože zcela typicky se při tom přepisu něco po**re. Detailně to rozebírá kniha, na kterou už jsem odkazoval.
Ještě na tom nejsem tak špatně, abych četl Viewegha.
13.2.2011 13:28 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Unit Tests
Jakýkoli test je lepší než žádný test, za čímž si stojím a je mi fuk, jestli s tím třeba nesouhlasíte.
Ano, s tím nesouhlasím. protože ten „jakýkoli“ test má typicky nulovou (nebo blízkou nule) vypovídací hodnotu o kódu, náklady na jeho psaní a údržbu ale zůstávají, resp. náklady na údržbu špatného testu špatného kódu jsou vyšší, dobře napsaný test není potřeba při změně implementace upravovat.
V žádném odstavci nezmiňuju testy, které ověřují postup operací namísto jejich výsledku (i když i to může být někdy užitečné).
Nezmiňujete je explicitně. Ale všechny tyhle testy, které intenzivně používají mock objekty, runtime úpravy kódu, DI apod. testují postup operací a ne výsledek.
Ke špatnému kódu je klíčové napsat testy ještě před jeho přepisem, protože zcela typicky se při tom přepisu něco po**re.
Pokud ovšem dokážete napsat opravdu jednotkové testy, které testují výsledek operací. Což je ale u špatného kódu velmi vzácný případ. Jinak si sice napíšete testy předem, ale ty vám po změnách kódu nebudou procházet (nebo spíš nepůjdou ani zkompilovat). Takže je budete muset pro nový kód upravit. K čemu pak ale takové testy jsou?
13.2.2011 14:11 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Unit Tests
Ono jaksi bez mocků (ať už magických nebo ručně vytvořených) takový jednotkový test (ve smyslu že testuje jednu izolovanou jednotku) nenapíšete – všechny objekty v programu mají závislosti, a ty závislosti právě mockujete. Jednak proto, abyste testované jednotce podstrčil vstupy, které chcete, a jednak pro zjišťování, jestli testovaná jednotka měla požadované efekty na svoje okolí. (Jinak řečeno, vstup nejsou jen parametry metody a výstup není jen její návratová hodnota.) Bez zástupných objektů (ať už jim budeme říkat stub, mock, fake nebo třeba Karel IV.) se prostě neobejdete.

Pokud jste terminologický purista a za mock považujete jen něco, co má record/replay/verify, pak máte samozřejmě pravdu a všechny testy, které používají mocky, ověřují postup. V takovém případě bych ale rád podotknul, že třeba takové Mockito umožňuje na verify úplně zapomenout (uživatel ho musí zavolat ručně), čímž se z mocků stávají vlastně stuby, a soustředit se na ověření stavu. To je to, co jsem měl na mysli. Mně to rozlišování mezi mocky a stuby přijde zbytečné, ale asi jsem to měl říct přímo.
Ještě na tom nejsem tak špatně, abych četl Viewegha.
13.2.2011 14:29 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Unit Tests
V dobrém objektovém kódu bude jeden objekt záviset jen na několika málo dalších jednoduchých objektech. Takže i ty mock/stub objekty pak budou jednoduché, často k tomu ani nepotřebujete žádnou knihovnu a často tomu ani mock objekty nebudete říkat. Ale nešlo mi ani tak o tu terminologii, jako spíš o to, že pokud máte objekt, který závisí na spoustě dalších složitých objektů, odpověď na otázku „jak takový objekt správně testovat“ není „doplnit mock objekty nebo stuby“, ale „rozdělit kód na menší objekty s menším počtem vazeb – a testování pak už půjde samo“. Někdy na to samozřejmě není čas – ale pokud se tazatel ptá na to, jak se to naučit, měl by se podle mne naučit to dělat správně, a pak už sám pozná, kdy si může dovolit něco ošidit, nebo si aspoň bude vědom toho, že něco nedělá dobře. Je to podle mne lepší, než se rovnou od začátku učit, jak kód „prasit“.
13.2.2011 14:58 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Unit Tests
pokud máte objekt, který závisí na spoustě dalších složitých objektů, odpověď na otázku „jak takový objekt správně testovat“ není „doplnit mock objekty nebo stuby“, ale „rozdělit kód na menší objekty s menším počtem vazeb – a testování pak už půjde samo“
Okay, tak v tomhle se neshodneme. Pokud ta refaktorizace není vyloženě triviální (ideálně jen posloupnost operací nějakého refaktorovacího nástroje, těm se dá už dneska docela věřit), jsem toho názoru, že odpověď je: Namísto těch složitých objektů použijte mocky a napište test. Potom refaktorujte. Postupujte po jednoduchých krocích, po každém kroku opravte test a ověřte, že pořád prochází. Oprava testu v takovém případě typicky znamená opravu kódu, který konstruuje strom objektů (setup fáze), možná přesun nějakých metod z jedné třídy do druhé, neznamená to, že by se ten test pořád musel překopávat od začátku do konce.

Netvrdím, že mocky jsou spása všehomíra, ale jak jsem říkal, "ledacos zvládnou vyřešit".
Ještě na tom nejsem tak špatně, abych četl Viewegha.
13.2.2011 15:25 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Unit Tests
Takhle to samozřejmě jde udělat. Ale takový test je k ničemu. Jediné, co se tím testuje, je trpělivost programátora, jestli dokáže tu samou změnu postupu promítnou do kódu i do testu. Pokud udělá programátor chybu v algoritmu, vzápětí upraví i test tak, aby kontroloval, že se provádí ten chybný krok v algoritmu. Takže testy mu budou pořád sedět, akorát výsledek nebude správný (což ale z testů nezjistí).
13.2.2011 16:29 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Unit Tests
Je o tom celá kniha, jak takovéhle věci dělat smysluplně a s minimálním rizikem. Pokud o tom Michael Feathers dokáže napsat 500 stran, já to na pár řádkách určitě neshrnu.
Ještě na tom nejsem tak špatně, abych četl Viewegha.
13.2.2011 12:16 Mira
Rozbalit Rozbalit vše Re: Unit Tests
Predevsim diky vam obema za reakce.

Na zaklade vznikle diskuze jsem si uvedomil, po cem presne patram - chtel bych ziskat schopnost/predstavu, jak psat testovatelny kod (a dale jak jej efektivne testovat).

Vyhovoval by mi zejmena nejaky zdarma dostupny material (webovy tutorial nebo knihu, kterou sezenu na univerzite v knihovne, nebo aspon stahnu z internetu kompletni pdf). Jakozto student nemam momentalne finance pro nakup vsech knih, ktere bych si rad poridil.

Knihu Working Effectively with Legacy Code se urcite pokusim ziskat (bohuzel kompletni pdf volne ke stazeni jsem zatim nenasel, v knihovne mame jediny vytisk a ten je dlouhodobe vypujceny). Stejne tak diky za odkazy na pokrocilejsi testovaci frameworky.

Pozn.: Momentalne pisu predevsim v Jave. Sve unit testy se zatim snazim psat prostrednictvim frameworku JUnit.

Diky Mira
13.2.2011 12:46 jos
Rozbalit Rozbalit vše Re: Unit Tests
můžu ještě doporučit klasiku TDD by Example, Kent Beck

a k tomu příkládku v dotazu - chceš jednak testovat co nejmenši jednotky práce a druhak jestli se aplikace chová předvídatelně když nastanou potíže; např.:

vrací kód modifikující obsah souboru správnej výsledek? (za předpokladu že bere string a ne cestu k souboru <= testovatelnost)

když se nepodaří vyrobit soubor, vylítne z kódu vyjímka?

atd.
13.2.2011 13:14 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Unit Tests
Dejte si do googlu writing testable code. Dostanete mimo jiné tohle a velmi pěknou Guide: Writing Testable Code (je tam i pdf). Pokud neznáte, doporučuju se před čtením seznámit s dependency injection, slušně vypadající úvod je ve wiki Google Guice.
Ještě na tom nejsem tak špatně, abych četl Viewegha.
13.2.2011 13:05 XY
Rozbalit Rozbalit vše Re: Unit Tests
Akurat vcera som zacal citat: Growing Object-Oriented Software, Guided by Tests (da sa stiahnut pdf z hotfile) a tak sa mi zapacila, ze som si ju rovno objednal.
13.2.2011 17:05 Sten
Rozbalit Rozbalit vše Re: Unit Tests
Pokud dělá složité věci, tak by si zasloužila rozdělit. Třeba na třídu, která obaluje soubor (+ unit testy) a třídu, která ten soubor mění (+ unit testy, které simulují soubor).

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.