Komentáře k článku

Testování v Pythonu

Python je moderní skriptovací jazyk, který je stále populárnější i mezi webovými vývojáři. Za svou popularitu vděčí nejen svému návrhu a implementaci, ale také množství knihoven a nástrojů, které pro tento jazyk existují. V článku se seznámíme se základními možnostmi, které Python nabízí pro testování.

Zpět na článek

32 komentářů k článku Testování v Pythonu:

  1. jakub vysoky [kvbik]

    kdo chce mit tecky i pro doctesty

    chvalim pouzivani unittest2, i kdyz te knihovne urcite jeste nejakou chvili potrva, nez nahradi napriklad nose (a i kdyz jejich puvodni zamereni mohlo byt malinko jine).

    u testovani se obecne mluvi o takzvane „zavislosti na teckach“ a pokud tedy nekdo chcete mit tecky take pro doctesty, nabizi puvodni knihovna unittest nasledujici moznost (a mozna i spoustu dalsich ;)):

    if __name__ == '__main__':
        import unittest
        import doctest
    
        suite = unittest.TestSuite()
        suite.addTest(doctest.DocTestSuite())
    
        runner = unittest.TextTestRunner()
        runner.run(suite)

    http://github.com/kvbik/bordel/blob/master/py/slova.py#L42

            1. imploder

              Re: Anketa

              Takže napíšu program třeba v Pythonu a počítač mi řekne, jestli dělá všechno jak má? A jak počítač ví, co po něm vlastně chci? On to neví, musí mu to někdo říct. A když ten někdo při tom udělá chybu, tak jsme zase tam, kde jsme byli.

              Na automatické ověřování se hodí testy. V důkazu, co někdo vymyslí, může být chyba. A ne pro každý program jde formální důkaz udělat.

              1. xx

                Re: Anketa

                On to neví, musí mu to někdo říct.

                Jistě, že musíte mít formální specifikaci toho, co má program dělat. Bez toho se nemá smysl bavit o korektnosti programu.

                Na automatické ověřování se hodí testy. V důkazu, co někdo vymyslí, může být chyba.

                Jenže v testu může být také chyba.

                A ne pro každý program jde formální důkaz udělat.

                IMO ve specifikaci jsou vlastnosti, co lze dokázat.

                1. imploder

                  Re: Anketa

                  Jenže v testu může být také chyba.

                  To může. Akorát test obvykle není složitější než samotný program.

                  Důkaz je skvělá věc – co víc si přát – ale případ „programy netestuju, všechno mám dokázané, tak testovat nepotřebuju“ je nereálný. Takový člověk by toho moc nenaprogramoval.

                  1. xx

                    Re: Anketa

                    Takový člověk by toho moc nenaprogramoval.

                    Ano, ale já se programováním neživím, takže mi to nevadí.

                    To může. Akorát test obvykle není složitější než samotný program.

                    Souhlasím.

                    Ale přesto by si měl každý uvědomit, že testy může pouze ukázat, že program nefunguje (s výjimkou konečných automatů, kde může dokázat i korektnost).

                    1. sg

                      Re: Anketa

                      Formalní přístupy jsou v dnešní době používané pouze ve specifických aplikacích (kritických aplikacích, tedy tam, kde sebelepší testsuite nestačí – ať ekonomicky nebo bezpečně). Navíc vedle nich se také používá klasické testování a statická analýza. Tento článek popisuje pouze testování, navíc pouze pro Python. Já osobně si nejsem vědom nějakého nástroje, který implementujte formální metody nad programy v Pythonu.

                      1. xx

                        Re: Anketa

                        Původně jsem reagoval na nabídku možností v anketě.

                        Já osobně si nejsem vědom nějakého nástroje, který implementujte formální metody nad programy v Pythonu.

                        To já také ne. Ale myslím si, že by nebylo příliš složité rozšířit třeba Coq, aby se daly vyextrahovat programy i v Pythonu.

            2. Honza Kral

              Re: Anketa

              Nikdo nerika ze testy nemuzou byt ve forme dukazu :)

              Jestli to pro vase problemy funguje a dokazete to tak nam ostatnim nezbyva nez vam zavidet. Cokoliv receno o automatickych testech to ale nerozporuje – vy jen testujete dukladneji pomoci dukazu.

      1. tiso

        Re: Anketa

        Chýba mi tam možnosť „ne, zatím“ alebo len „ne“ bez toho dodatku o zdržovaní a zvyšovaní nákladov, s ktorým nesúhlasím.

        1. Martin Malý

          Re: Anketa

          Pokud ne, tak by mě zajímalo, proč ne – snad nejčastější odpověď, se kterou jsem se setkal, byla právě ta o zdržování a zvyšování nákladů, proto jsem ji tam dal. Možná by stálo za to udělat anketu „proč netestujete?“ ;)

          1. tiso

            Re: Anketa

            Áno, to sú tie najčastejšie výhovorky prečo netestovať. Ale s touto škatuľkou nechcem mať nič spoločné.
            Prečo netestujem? Ešte som neprenikol do testovania tak hlboko (teória, výber správnych nástrojov, Best/Worst practices …), aby som týmto spôsobom pracoval.

          2. Karel Minařík

            Re: Anketa

            Nejen anketu, nejlíp článek nebo sérií rozhovorů :) Já vždy na workshopech říkám, že _každý_, i ten kdo netestuje, umí vyjmenovat důvody, proč jsou automatizované testy výhodné. A právě u těch odpovědí proč _netestovat_ to začne být zajímavé.

            Mimochodem, hlavní důvod je opravdu ten, že lidé nevědí _jak_ na to. Zmiňované „není čas, nejsou peníze, nejsou lidi“ začíná být tak trochu fáma (platí to jen u absolutně hibernovaných týmů) – právě proto, že většina lidí dobře chápe, že je velmi slabý argument…

        1. Almad

          Re: Coverage

          Jeden čas jsme zkoušeli i Titusovu verzi, ale s novou verzí coverage neni důvod, Ned ji přece jenom udržuje víc ,)

          Každopádně jedeme přes nose, takže jestli –with-coverage nebo –with-figleaf neni moc rozdíl :)

          Navíc je taknějak funkční i branch coverage, ale s tou jsme si zatím moc nehráli.

    1. Honza Kral

      Re: Coverage

      Jsem velky fanousek coverage ale ma to nekolik uskali: neni to spolehliva metrika na mereni kvality testu, jen ukazuje (podobne jako testy same) ze je neco spatne, ne ze je neco dobre.

      Nejlepsi vyuziti coverage je pr trackovani trendu – zda se pokryti zvetsuje ci zmensuje – je to dulezite abychom vedeli zda novy kod ktery pridavame je otestovany nebo pridavame featury bez testu. V kazdem zdravem projektu by se mela coverage zvysovat nehlede na absolutni hodnotu. samozrejme idealni je mit tohle v CI nastroji (hudson, buildbot, …) ktery je k tomu schopen prilepit dalsi info (jako kdo nejvic snizuje ci zvysuje coverage projektu)

      1. msgre

        Re: Coverage

        Ze souvislostí mezi procenty pokrytí a kvalitou testů jsem už vyrostl… :)

        Mě se Coverage osvědčil hlavně v případech, když si *myslím* že mám proklepnuté všechny důležité věci. Omyl! Vždycky se najde nějaké „nepokryté“ místo, na které jsem zapomněl (nejčastěji nějaká větev if podmínky).

        PS: figleaf neznám, díky za tip!

    1. Martin Malý

      Re: Cenzura na Zdrojáku?

      Protože byly naprosto offtopic, netýkaly se ani tématu článku, ani tématu vlákna, ale existence diskusního tématu samotného. Na takové hovory tu je patřičné vlákno v diskusním fóru, kde lze diskutovat o „cenzuře“ a ztraceném času doalelujá, aniž by to rušilo ty, co si přišli přečíst článek a komentáře k tématu.

  2. Michal Hořejšek

    assertRaises

    V článku v části popisování Unittestů jsou popisovány metody, které lze použít a poslední zmiňovaná, assertRaisese, je napsána s překlepem – poslední e v názvu není. Název je assertRaises.

  3. lzap

    Pěkné

    Hezké, ale článek by se měl jmenovat spíše Unit testy v Pythonu. Je celý věnovaný jen a pouze unit testům. Testování má mnoho podob a tváří.

    JUnit je spíše inspirován Smalltalkem. Nevhodně zvolené slovo „založen“.

    Moc pěkně zpracováno.

  4. myneur

    O čem by mohl být další článek

    V diskusi tu zazněl podle mě trefný názor proč lidi netestují – neví jak na to. To by mohl být námět na další článek – ukázat testování v praxi na nějakém fragmentu komplexnějšího systému. Úvodů do testování a jiných testovacích hello worldů je po netu mnoho, ale jak pojmout testování jako celek, kde se objeví nějaké zapeklitosti, na co si dát pozor, jak to prostě vypadá u složitějších projektů. Samozřejmě se lze podívat do testů již existujících projektů třeba na Git Hubu, ale dobré vedení by určitě lidem velmi usnadnilo úvodní tápání a mohlo změnit přístup k testům.
    Kdy už pythoní unittest nestačí a hodí sane nebo nose a jak to využít. A v nějakém dalším díle třeba až jak na continuous integration.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3214