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í.
Jestli jste někdy řešili nasazování aplikace, asi víte, že všechno odladit může být celkem zdlouhavá záležitost. Dokážete si představit, že na to máte jen týden? Že je to nemožné? Není! Jde to a ani to nemusí být příliš složité.
Reportáž z virtuální konference FOSDEM. Minule jsem popsali Go room, dnes se věnujeme monitoringu a observability.
Mikrofrontendy jsou zajímavá adaptace konceptu microservices pro potřeby frontendového vývoje. Podívejte se, co to v praxi obnáší a proč jsme se v Seznam.cz rozhodli vyvinout náš vlastní microfrontend framework, Merkur.
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
Re: Anketa
Proč v anketě není volba „Ne, píšu korektní kód, takže testy nepotřebuji.“?
Re: Anketa
Protože nikdo takový neexistuje. ;)
Re: Anketa
Protože jsem chtěl, aby možnosti v anketě byly alespoň trochu reálné.
Re: Anketa
Co je na tom nereálného?
Re: Anketa
Nikdo není neomylný.
Re: Anketa
Korektnost programu lze dokázat a důkazy může počítač automaticky ověřit.
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.
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.
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.
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).
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.
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.
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.
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.
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?“ ;)
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.
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…
Re: Anketa
Protože apríl byl už skoro před 3 týdny.
Re: Anketa
Protože to není o korektnosti psani kódu ale o funčnosti.
Coverage
Honzo,
používáte v Centru při testování nějakou variantu Coverage?
Díky za odpověď
Re: Coverage
Ano.
Re: Coverage
A kterou? :)
Tu od Neda Batcheldera, nebo máte zkušenosti i s jiným řešením?
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.
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)
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!
Cenzura na Zdrojáku?
Proč byl komentář Daniela Steigerwalda, můj a uživatele yy odstraněn?
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.
Re: Cenzura na Zdrojáku?
Díky za odpověď.
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.
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.
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.