Zabíjíme mutanty (diskuse)

[Max]

Moc pěkné počtení, díky, neznal jsem (ale zase nejsem programátor). Jaký sw jsi zkoušel/používáš pro mutační testy? Že bych se podíval na konkrétní řešení.
díky
Zdar Max

[Pavel Křivánek]

Osobně používám MuTalk pro Smalltalk/Pharo, takže asi mimo okruh zájmu většiny čtenářů.

[Max]

Souhlasím :).
Zdar Max

[johnyK]

to je podle mne dobra ukazka, jak by melo v budoucnu abcl vypadat. Takovy blog je vpodstate technicky clanek, pod kterym je diskuze. Je to treba jen redakcne upravit, ale no te namaji vlastnici silu , chut a nebo napady. Proto fandim te myslence pana Snajdra, ze si to musime udelat sami a tak jsem take jeho vizi pochopil.

Ted k tomu tematu. Vidim v tom pohled informatika a vseobecne tendenci videt v IT vsechno pres projektove bryle. Lidem z jinych 'prumyslu' je to az smesne, jak se propaguje 4. prumyslova revoluce a hlavni ulohu v tom bude hrat IT, ktera se svym celym teoretickym vyzkumem za poslednich 30 let snazila vylepsit ty projekty.

Projekt a prumysl jsou antagonismy.

Ale na skolach se to tak momentalne uci a v praci se to tak take provozuje. Videt je to na inzeratech, kolik se hleda testeru. Davam tomu minimalne jeste 30 let, nez se IT pouci u jinych oboru.

[debian+]

to je podle mne dobra ukazka, jak by melo v budoucnu abcl vypadat

+1, můžeme jen doufat

[Aleš Kapica]

Ale ono takhle, alespoň tedy z mého pohledu, vypadá – pokud aktivně využíváš blokování. Sice tím přijdeš sem tam o nějaký blogpost nebo zprávičku která by mohla být zajímavá, ale pořád se to vyplatí.

[Pavel Křivánek]

Mohl byste to trochu rozvést a ušetřit nám pár desetiletí tápání?

[johnyK]

mohl , ale nemelo by to cenu.

Jak rikal Max Planck:

„Nová vědecká pravda se neprosazuje tím, že se její odpůrci dají přesvědčit, ale spíše tak, že odpůrci pomalu vymřou a dorůstající generace se s pravdou seznamuje hned na počátku.“

Jinak vazne - to neni na kratkou odpoved. Pripravuji neco trochu obsirnejsiho, kde to chci vysvetlit, asi napisi muj prvni blog

[Martin Tůma]

Koukám, že "Kult jednotkových testů" je stále v kurzu. Zápisek sice správně poznamenává, "že (jednotkové testy) většinou vlastně nic netestují", ale vyvozovat z toho, že "jediné správné TM" řešení tohoto stavu je začít testovat jednotkové testy, je zcela zcestné. A konečně, tvrdit, že "Do budoucna se určitě dále zvýší důraz na kvalitu testování." je už pouhé zbožné přání.

Ano, existují kategorie SW, kde takto důkladné testování má svůj smysl (kritické řídící systémy, systémy přes které tečou velké peníze, ...), ale takových je naprostá minorita. Pro většinu SW není, slovy klasika, "testování zasazeno do reálných ekonomických rámců". Konec konců je tady o tom zrovna pěkný zápisek od Bystroushaaka. Důvod, proč všechny čtečky "fungují" tak nějak podobně není ten, že by vývojáři jejich SW nikdy neslyšeli o testování, ale ten, že aby výrobce přežil, musí v současném konzumním stylu vývoje elektroniky chrlit novou verzi s novými funkcemi co půl roku a tudíž nemá ani náhodou čas/zdroje na to, psát k tomu nějaké jednotkové testy (které stejně nic netestují). A to se v dohledné době nezlepší, spíš naopak.

Aby jednotkové testy měly vůbec nějaký smysl, musí se do nich investovat alespoň 2x tolik práce (a to zdaleka ještě nejsme tam, kam se dá reálně zajít), co do samotného testovaného SW. Což znamená, že při stejných omezených zdrojích máte buď SW s třetinou funkcionality a testy, nebo SW s plnou funkcionalitou a řekněme 5% chyb navíc, které by ty unit testy podchytily. Pro drtivou většinu SW je to jasná volba, pokuď tedy jste ten, kdo to platí a ne "hipsterský programátor který má na všechno unit testy protože je to dneska cool".

[Josef Kufner]

Mně se tento přístup s mutanty líbí, neboť je z principu plně automatizovatelný a dokáže efektivně prověřit, na co testy přijdou a na co nikoliv. Vygenerovat chyby a spustit testy znovu je docela jednoduchý přístup a nepřijde mi, že by tam byly nějaké záludnosti, jaké jsou běžné u automatického generování testů.

Pak mi také přijde, že v blogu zmiňovaná podmínka na 100% pokrytí je zbytečná. Mělo by stačit omezit mutace na testy pokrytý kód. Tím pádem není potřeba psát zbytečné a drahé testy na všechno, ale stačí jen testovat to, co má smysl a co se blbě otestuje prostým proklikáním se aplikací.

[Cal]

Koukám, že "Kult jednotkových testů" je stále v kurzu. Zápisek sice správně poznamenává, "že (jednotkové testy) většinou vlastně nic netestují" ...

Nevim jestli utocis jen na unit testy nebo automatizovane testovani obecne.

Degenerovane unit testy, ktere nic netestuji jsou prikladem testovani na spatne urovni. Typicky nejake service metody, ktere jen volaji nizsi vrstvy a zadnou zajimavou testovatelnou logiku nemaji. V takovem pripade je potreba jit na hrubsi granularitu a testovat business transakce (komponentni/integracni testy). Ve skutecnosti mnoho vhodnych pouziti pro klasicke nizkourovnove unit testy v typickych aplikaci neni.

Ano, existují kategorie SW, kde takto důkladné testování má svůj smysl (kritické řídící systémy, systémy přes které tečou velké peníze, ...), ale takových je naprostá minorita. Pro většinu SW není, slovy klasika, "testování zasazeno do reálných ekonomických rámců".

IMHO zalezi na velikosti a komplexite aplikace. Pokud si delas skript/aplikaci pro sebe, tak testy obecne velky vyznam nemaji.

Ale jakmile aplikaci vyviji vic lidi, obcas se stridaji a vyvoj probiha roky nebo desetileti, tak aplikace automatizovane testy urcite potrebuje.

Jinak casem znalost o tom, co ta aplikace dela a jestli to vlastne delat ma nebo ne se proste ztrati. Lidi se zacnou bat aplikaci menit, protoze to rozbije pro ne nezname use casy a zacne to hnit, coz jen akceleruje jine problemy.

[Martin Tůma]

Nevim jestli utocis jen na unit testy nebo automatizovane testovani obecne

Útočim na cargo-kult unit testů. Jiné testování, například "funkční testy" tady teď neřešim. Ale i u těch je v první řadě nutné si položit otázku, kolik to bude stát a co to za tu cenu přinese. U unit testů je poměr cena/výkon extrémně nízkej, přesto se neustále rojí "moderní vývojáři", kteří si život bez unit testů nedovedou představit...

Ale jakmile aplikaci vyviji vic lidi, obcas se stridaji a vyvoj probiha roky nebo desetileti, tak aplikace automatizovane testy urcite potrebuje. Jinak casem znalost o tom, co ta aplikace dela a jestli to vlastne delat ma nebo ne se proste ztrati. Lidi se zacnou bat aplikaci menit, protoze to rozbije pro ne nezname use casy a zacne to hnit, coz jen akceleruje jine problemy.

Právě že si nemyslim, že by unit testy měly suplovat funkci lidsky srozumitelný dokumentace a jednoduše a čitelně napsanýho zdrojového kódu. Pokuď "se do toho bojí lidi šáhnout", je to špatně napsaný a unit testy to nespasí.

[Bystroushaak]

U unit testů je poměr cena/výkon extrémně nízkej, přesto se neustále rojí "moderní vývojáři", kteří si život bez unit testů nedovedou představit...

Hele, a ty jsi programátor a programuješ na každodenní bázi? Já nevím jestli jsem moderní vývojář, ale fakt si to bez nich neumím představit. Respektive všechny mé pokusy a všechny code base které jsem viděl byly o tolik jednodušší s unittesty, že je pro mě až nepochopitelné, jak by ses bez nich mohl obejít. Používáš nějakou formální verifikaci? Nebo jakým způsobem ověřuješ, že tvoje zadaní funguje pro konkrétní data, a nikoliv jen strukturu dat? Jak děláš refactoring? Jak víš že tvůj program funguje? Máš nějaké testery, nebo co?

Právě že si nemyslim, že by unit testy měly suplovat funkci lidsky srozumitelný dokumentace a jednoduše a čitelně napsanýho zdrojového kódu. Pokuď "se do toho bojí lidi šáhnout", je to špatně napsaný a unit testy to nespasí.

Spíš dodávají další formální specifikaci toho, co má kód dělat a skutečně ověřují, že to dělá. Typový systém definuje strukturu, ale skoro nikde už neřeší obsah struktury. Jak se program skutečně chová se nedozvíš, pokud k tomu nemáš formální specifikaci, což je zase o tolik náročnější než unittesty, že se tomu většina lidí proste vyhýbá.

[Martin Tůma]

Píšeš v Pythonu a vzýváš unit testy, tedy jednoznačně splňuješ definici "moderního vývojáře"

Ve skutečnosti většina SW, který používáš, včetně jádra OS, žádné unit testy nemá a přesto očividně funguje. Popravdě řečeno, celkem mě překvapuje, že zrovna ty si se nad tím, proč to vývojářům tohoto SW funguje, přesto, že ty se bez unit testů neobejdeš, ještě nezamýšlel. Těch faktorů je samozřejmě celá řada, například zkušenosti tady hrají velkou roli, ale ten hlavní důvod je jinde a kde je problém je vidět už z těch otázek. Jde o to, že účelem SW není, aby 100% plnil nějakou formální verifikaci nebo měl 100% pokrytí unit testy, ale aby dostatečně dobře plnil funkci, pro kterou je určen. Přičemž to "dostatečně dobře" je něco zcela jiného u řízení jaderného reaktoru a 365. blogískovacího systému v PHP.

Odpověď na tvoje otázky tedy je: jak kde a jak co. Pokuď tě to zajímá konkrétně, tak když jsme dělali v SYSGO pro Airbus, tak to byly především testy všeho druhu včetně unit testů. V Avastu jsme měli jenom funkční testy (a miliony testerů ) a třeba GPXSee je příklad SW, který kdyby měl mít vůbec nějaké testy, tak zdaleka není tam co dneska je.

[Bystroushaak]

Ve skutečnosti většina SW, který používáš, včetně jádra OS, žádné unit testy nemá a přesto očividně funguje. Popravdě řečeno, celkem mě překvapuje, že zrovna ty si se nad tím, proč to vývojářům tohoto SW funguje, přesto, že ty se bez unit testů neobejdeš, ještě nezamýšlel.

Tak zrovna jádro je testované docela extenzivně ^{[třeba 1]}. To že to nejsou zrovna unittesty je podle mě spíš slovíčkaření, než co jiného.

Těch faktorů je samozřejmě celá řada, například zkušenosti tady hrají velkou roli

Já bych fakt rád věřil, že někdo je schopný psát bez testů, protože má zkušenosti, ale úplně se to vymyká všemu co jsem kdy kde viděl. Vždycky když jsem na někoho takového narazil, tak se to nakonec ukázalo jako úžasný footgun, který ho střelil do nohy ve chvíli, kdy to vůbec nečekal.

Jde o to, že účelem SW není, aby 100% plnil nějakou formální verifikaci nebo měl 100% pokrytí unit testy, ale aby dostatečně dobře plnil funkci, pro kterou je určen. Přičemž to "dostatečně dobře" je něco zcela jiného u řízení jaderného reaktoru a 365. blogískovacího systému v PHP.

S tím samozřejmě souhlasím. Jenže to je jen primární účel, takový nejmenší požadavek, abys to vůbec mohl nazvat řešením nějakého problému.

Sekundární účel je, aby se nedal jednoduše rozbít špatným uživatelským vstupem, nebo jinými slovy, byl robustní, dále pak aby zdrojový kód byl přehledný, zdokumentovaný a jednoduše upravitelný, přijde-li někdy požadavek na úpravu (jakože přijde).

Testy sice rozhodně neřeší všechny problémy, ale umožní ti například zvýšit tu robustnost, ověřit korektnost některých pod-algoritmů a mimo jiné také lepší úpravy kódu, protože můžeš bez obav refactorovat.

Samozřejmě nechci tvrdit, že to vše dělají unittesty, důležitou roli hrají testy obecně, ať už jsou třeba integrační, nebo API, nebo funkční.

Já jen prostě jsem trochu překvapený tím, že by někdo mohl vůbec něco namítat proti testům. Určitě chápu, že bezhlavé 100% pokrytí testy, kde pokryješ každou blbost ve skutečnosti nic neřeší, ale brát to jako důvod proti testování obecně?

[Michal Kubeček]

Tak zrovna jádro je testované docela extenzivně [třeba 1]. To že to nejsou zrovna unittesty je podle mě spíš slovíčkaření, než co jiného.

LTP je víceméně až ex post testování a podle těch testů, se kterými jsem se potkal, to vypadá, že velká část je tam až jako reakce na konkrétní nalezené chyby. Testy, které by se přidávali už současně s novým kódem, to je celkem nová záležitost (a i tam je pokrytá dost malá část).

Určitě chápu, že bezhlavé 100% pokrytí testy, kde pokryješ každou blbost ve skutečnosti nic neřeší, ale brát to jako důvod proti testování obecně?

Ale právě o tom tu ostatní mluví. Nemyslím, že by někdo tvrdil, že je špatné proaktivně testovat. Pokud tu někdo proti něčemu vystupoval, byla to právě taková to klišé typu "jak se na všechno nenapíšou unit testy, projekt je k ničemu" (často s implicitním "a když ano, o nic dalšího se starat nemusíme").

[JS1]

Ja treba ted pisu v Haskellu a C SAT solver a nemam tam unit testy. Hodne toho zachyti typovy system, taky to mam strategicky prolozene asserty (na predpoklady, ktere jsou dulezite a ktere nezachyti typovy system), a pak to cele testuji end-to-end kombinaci Quickchecku (coz je naprosto vynikajici vec) a par jednoduchych rucnich meznich pripadu.

Ono unit testy maji i pri refaktorovani svoji cenu. Ja jsem zjistil, ze psat v Haskellu te nuti psat velice abstraktnim zpusobem, delit vhodne problem tak, abys v podstate unit testy nepotreboval. Kdyz jsem psal v jinych jazycich, i v Pythonu, mel jsem vzdy problem psat kratke funkce. V Haskellu je to tak nejak nutnost. A pokud pises hodne kratkych funkci, ktere navic mezi sebou otestuje typovy system, potrebujes refaktoring dost malo - je jednodussi obvykle znovu napsat kod te male funkce, kterou potrebujes zmenit, nez modifikovat stavajici funkci.

Ono v programovani existuji tri hlavni strategie, jak predejit chybam, a testovani je jen jedna z nich (bohuzel az prilis popularni na ukor zbylych dvou). Druhe dve jsou lepsi abstrakce a asserty. (Mozna bych z toho mohl udelat metodologii AAA - Abstract, Assert, Attest - a vydelat miliony. )

Lepsi abstrakce znamena napsat program citelne tak, aby ses vyhnul chybam. Napriklad nemit pointery je abstrakce. Definovat si nebo jen pouzit nejakou monadu, aby jsi nemusel funkce znovu stejne rucne kombinovat, je abstrakce. Tohle je vec, kde Haskell pomaha vyborne.

Asserty jsou asi jasne, to jsou testy za behu (idealne se daji vypinat a zapinat v buildu nebo i v runtime) na invarinty, preconditions, postconditions. Asserty, dalo by se rict, testuji data, ktera proudi funkcemi. Idealni je pak pouzivat asserty v kombinaci s necim, jako je QuickCheck.

Navic, jak uz jsem psal niz. Testy jsou (v limitnim pripade) totez jako napsat program dvakrat. Tomu se muzes casto vyhnout tim, ze proste budes davat vic pozor a napises to dostatecne citelne tak, aby bylo proste jasne, ze v tom neni chyba. Zase, v tomhle vyborne pomaha funkcionalni pristup.

(Taky jsem zacal psat relevantni matematiku v TeXu. Je to po mnoha letech nezvyk a skoro bych rekl omyl, psat matematiku pomoci lidskeho a nikoli pocitacoveho jazyka, prave proto, ze overitelnost je horsi. Kupodivu, i pres absenci unit testu, podstatna cast matematiky je spravne.)

[deda.jabko]

Asserty jsou asi jasne, to jsou testy za behu (idealne se daji vypinat a zapinat v buildu nebo i v runtime) na invarinty, preconditions, postconditions. Asserty, dalo by se rict, testuji data, ktera proudi funkcemi.

Mne asserty nikdy neprisly moc uzitecne, jelikoz odhaluji typicky stejny chyb jako unit-testy + hlidani code coverage. Proto vetsinou pouzivam to druhe a asserty jen pri ladeni.

Lepsi abstrakce znamena napsat program citelne tak, aby ses vyhnul chybam.

Haskell nepouzivam, ale ve Scale se mi pravidelne deje, ze zacnu postupne vrstvit jednu abstrakci na druhou az je zakryta cela puvodni myslenka algoritmu.

Kdyz jsem psal v jinych jazycich, i v Pythonu, mel jsem vzdy problem psat kratke funkce.

Unit testy plni jeste jednu neprimou, ale z principu dulezitou, ulohu a tou je, ze te nuti psat testovatelny kod. Tim kod ziskava docela zadouci vlasnosti. Jednak te to nuti psat mensi testovatelne metody, druha vec je, ze te nuti psat kod proti rozhranim, ne proti konkretnim objektum. Tuto ulohu neni mozne jen tak zanedbavat.

[JS1]

Mne asserty nikdy neprisly moc uzitecne, jelikoz odhaluji typicky stejny chyb jako unit-testy + hlidani code coverage.

Na obranu assertu - podle me jsou uzitecne na testovani dat, ktera vstupuji do funkci, pripadne na testovani spravnosti nejakeho vnitrniho stavu. Navic jelikoz jsou to vlastne podminky, testuji libovolne velkou mnozinu pripadu.

Ale tak me napada, kdyz mas n end-to-end testu a m assertu, tak je to trochu podobne, jako kdybys mel n*m unit testu. Mozna timhle stylem by se dalo na unit testech dost usetrit.

Haskell nepouzivam, ale ve Scale se mi pravidelne deje, ze zacnu postupne vrstvit jednu abstrakci na druhou az je zakryta cela puvodni myslenka algoritmu.

Nevim, zda se mi, ze se tomu neda moc vyhnout. Abstrakce je k tomu, aby clovek snaze pochopil program, tzn. vzdy se neco skryje a neco necha ukazat. Cim vetsi program, tim obtiznejsi bude ho pochopit at uz z jakehokoli uhlu. Volba tech abstrakci je dost svobodna a je jen na tobe, co se rozhodnes zakryt a zduraznit.

Unit testy plni jeste jednu neprimou, ale z principu dulezitou, ulohu a tou je, ze te nuti psat testovatelny kod.

To je mozna pravda, ale Haskellovska purity k tomu cloveka nuti tak jako tak.

[deda.jabko]

Na obranu assertu - podle me jsou uzitecne na testovani dat, ... Ale tak me napada, kdyz mas n end-to-end testu a m assertu, tak je to trochu podobne, jako kdybys mel n*m unit testu.

V principu jsou asserce a unit testy ortogonalni pojmy. Asserci chapu v tom smyslu, ze zajisti, ze vstupni/vystupni hodnoty splnuji pozadovana kriteria. Testy maji testovat, ze dany kod pracuje spravne. Takze ta uvaha n*m je v podstate korektni.

Mozna timhle stylem by se dalo na unit testech dost usetrit.

Test potrebujes k tomu, abys overil, ze kod opravdu bezi a nespadne ti na nejake neplatne asserci. Zde je uloha testu nenahraditelna (pokud teda nemas zavislostni typy). Navic, ze zkusenosti unit testy se mi lip navadi na to, aby se vyzkousely vsechny mozne vetve programu, nez kdyz pouziju volne lezici asserce v kodu.

Nevim, zda se mi, ze se tomu neda moc vyhnout. Abstrakce je k tomu, aby clovek snaze pochopil program,

Ja se domnivam, ze je potreba se tomu vyhnout a stanovit rozumnou miru abstrakce, pro danou ulohu. Ty apriori predpokladas, ze cim vyssi abstrakce, tim je to uzitecnejsi, ale to neodpovida zpusobu, jakym clovek uvazuje. Kdyz chces secist utratu, tak s cenami pracujes jako s celymi cisly a ne treba jako s komutativni grupou. Do prace jezdis (napr.) tramvaji, neuvazujes nad tim, ze jezdis draznim vozidlem. Tyto abstrakce v ti dane situaci moc nepomohou, jen popis problemu komplikuji.

Uroven abstrakce je potreba volit podle aktualni situace. A na co narazim v te Scale (a v Haskellu to bude jeste horsi), ze je problem najit tu hranici, kdy je ta abstrakce jeste prinosna a kdy uz zastira puvodni myslenku.

To je mozna pravda, ale Haskellovska purity k tomu cloveka nuti tak jako tak.

Bavime se tu ale o beznych programovacich jazycich.

[Josef Kufner]

Asserty a testy se liší v tom, kde se kontroluje nutná podmínka. Když se napíše do kódu, je to assert, když do testu, je to … ehm … test. Pointa je, že testy kontrolují program proti rozhraní, kdežto asserty kontrolují konzistenci vnitřního stavu, ke kterému testy nemají přístup. Testy tedy mohou jen vyvolat všechny cesty kódem, ověřit zevrubně správnost výsledku a nechat na assertech kontrolu detailů. Pak m*n neplatí.

[JS1]

To neni uplne pravda. Muzes mit assert, ktery kontroluje spravnost vstupnich dat (klasicky, test na nenulovy pointer), nebo dokonce assert, ktery kontroluje spravnost funkce (podobne jako unit test).

Napriklad muzes mit funkci nasobeni a assert, ktery overi, jestli je vracena hodnota 0, pokud aspon jeden z operandu je 0.

[Josef Kufner]

Jo, takové aserty je dobré mít a dávají smysl. Ale jakmile je kód odladěný, nemělo by se stávat, že selžou. Vstupní data by měla být ošetřena i bez assertů a mělo by to dávat smysluplné a uživatelsky přívětivé chybové hlášky.

[JS1]

Ano, nemelo. Stejne jako by se nemelo stavat NullPointerException, coz je de fakto assert. Paradoxne by se prave tomu dalo casto predejit, pokud by se (uzivatelsky definovane) asserty vice pouzivaly - aplikace by spadla na ten assert a bylo by okamzite jasne, proc.

[Martin Tůma]

Tak zrovna jádro je testované docela extenzivně ^{[třeba 1]}. To že to nejsou zrovna unittesty je podle mě spíš slovíčkaření, než co jiného.

Ne to rozhodně není slovíčkaření. Když ze sousloví vodní polo odstraníš slovo "vodní", dostaneš zcela jiný sport a stejně tak dostaneš "zcela jiný sport", pokuď ze sousloví unit testy odstraníš to "unit". Celý ten můj rant proti kargo-kultu unit testů je právě o tom slovu "unit".

Já bych fakt rád věřil, že někdo je schopný psát bez testů, protože má zkušenosti, ale úplně se to vymyká všemu co jsem kdy kde viděl. Vždycky když jsem na někoho takového narazil, tak se to nakonec ukázalo jako úžasný footgun, který ho střelil do nohy ve chvíli, kdy to vůbec nečekal.

Reálný svět je plný lidí, co píšou bez testů a nemusí jít jenom o vývojáře kernelu. Že se občas střelíš do nohy, to se ti stane i s testy, existence testů může (ale nemusí) kadenci střelbi snížit, ale je to jenom jeden z prostředků, ne jediný možný.

Já jen prostě jsem trochu překvapený tím, že by někdo mohl vůbec něco namítat proti testům. Určitě chápu, že bezhlavé 100% pokrytí testy, kde pokryješ každou blbost ve skutečnosti nic neřeší, ale brát to jako důvod proti testování obecně?

Testy nejsou Holocaust, aby se nesměly zpochybňovat... Minimálně zvážit jejich přínos vzhledem k nákladům je zcela relevantní postup. Ale jak už psal Michal Kubeček, proti testům obecně tady nikdo, ani já, nevystupuje.

[podlesh]

Přidávám se a potvrzuji z praxe, že (unit) testy jsou k nezaplacení. A to i z ekonomického hlediska - rozhodně se vyplatí. Samozřejmě, hodně záleží na tom co se testuje a jak dobře to jde. Prostor pro cargo cult je velký a u spousty aplikací to dost dobře nejde. Dobrým kompromisem je dělat unittesty na bugfixy u zásadních bugů v logice kódu.

Pokud to znamená že jsem "mlamoj", tak se klidně hrdě přiznám že jsem již 15 let moderním mlamojem.

Zrovna minulý týden jsem kroutil hlavou nad jedním bugem, který byl opravou jiného bugu způsobeného opravou jiného bugu způsobeného jinou opravdou... tři release za sebou obsahovaly naprosto dementní chyby... unittest byl hotový za hodinku... a stejně se se "klasický" vývojář zeptal "opravdu je potřeba na to psát test"?

[deda.jabko]

Pokud to znamená že jsem "mlamoj", tak se klidně hrdě přiznám že jsem již 15 let moderním mlamojem.

Pridavam se.

Programovat bez testu (vcetne tech jednotkovych) me casto prijde jako jezdit na kole po mokre rimse petipatrove budovy. Tech momentu, kdy clovek muze udelat chybu je tolik, ze to za to nestoji. Nedokazal bych spocitat, kolikrat me testy zachranily pred nejakym "chytrym vylepsenim" a nestydim se za to, ze pocet radku testu mam nekdy vetsi nez je uloha samotna.

[Bystroushaak]

IMHO zalezi na velikosti a komplexite aplikace. Pokud si delas skript/aplikaci pro sebe, tak testy obecne velky vyznam nemaji.

Tohle jde proti všem mým zkušenostem. Jakmile píšeš něco jen trochu komplexnějšího, tak psát to bez unittestů je cesta do pekla plného bolesti a utrpení. Například cokoliv co něco parsuje se bez testů naprosto neobejde.

Ale jakmile aplikaci vyviji vic lidi, obcas se stridaji a vyvoj probiha roky nebo desetileti, tak aplikace automatizovane testy urcite potrebuje.

Další věc, kterou unittesty přinášejí je refactoring, který si bez nich ani nedokážu představit.

[Cal]

Jakmile píšeš něco jen trochu komplexnějšího, tak psát to bez unittestů je cesta do pekla plného bolesti a utrpení. Například cokoliv co něco parsuje se bez testů naprosto neobejde.

Tak treba parsovani je takovy typicky enkapsulovany problem, ktery se da pekne testovat unit testy. Ale zda se mi, ze tolik takovych v typickych dejme tomu enterprise aplikacich neni.

Kdyz se podivam treba na takove kontrolery nebo servisni tridy vicevrstve aplikace, tak ony takovou pekne enkapsulovanou logiku nemaji - vetsinou jen volaji nizsi vrstvy typu uloz neco do databaze. Test pak vypada tak, ze namokujes vsechny ty zavislosti a jen poslouchas jestli tohle a tohle bylo volane s takovym parametrem. Ve vysledku nic zajimaveho netestujes. Skutecnou chybu takove testy malokdy odhali. Naopak produkuji spoust false negatives kdyz se rozbiji pri kazdem refactoringu.

Kdy se automatizovane testy oplati psat a kdy ne zalezi hodne na konkretni situaci - jejich cena i prinos se muze dramaticky lisit projekt od projektu. Napr. pokud pises knihovnu matematickych funkci, tak tam jsou unit testy no-brainer - nizka cena, obrovsky benefit.

Další věc, kterou unittesty přinášejí je refactoring, který si bez nich ani nedokážu představit.

Opet si myslim ze refactoringu pomahaji pouze pokud je problem (a refactoring) enkapsulovany v te dane "jednotce". Jakmile refactorujes ty jednotky (tridy) a vztahy mezi nimi, tak se unit testy sesypou aniz by poskytly nejakou cennou informaci - prave protoze netestuji skutecne use case / ficury ale mnohem nizsi level, ktery je vlastne jen implementacni detail ("X zavola Y s parametrem Z"). Na refactoring se mi daleko vic osvedcily integracni/komponentni/API testy.

[Josef Kufner]

Testování je vždy proti nějakému rozhraní. U knihoven a nejnižších vrstev aplikace je to jednoduché a rozhraní je zřejmé a vhodné pro klasické unit testy. U vyšších vrstev, které jen slepují věci dohromady, to ale moc nejde. Navíc ani nemá většinou moc smysl něco mockovat, neboť se to za chvíli zas rozbije. Lepší přístup je testovat aplikaci jako celek a vhodným sestavením/zaměřením testů izolovat testované komponenty. Například se dá napojit na uživatelské rozhraní a testovat celkem jednoduché scénáře ve stylu něco upravím a kouknu se, že to tam opravdu je. V kombinaci s asserty a smysluplným vyhazováním výjimek se aplikace zkontroluje sama a test je docela jednoduchý a oddolný vůči změnám v aplikaci.

V případě refactoringu dává smysl napsat si testy, které ověří konkrétní požadované vlastnosti, které mají refactoring přežít. Například pokud se volá nějaká služba a chci refactorovat volající aplikaci, je rozumné testem projít typické scénáře a logovat volání služby. Při refactoringu můžu aktualizovat testy na nové rozhraní té aplikace, ale dokud nesáhnu na logy volání, tak mám jistotu, že jsem to nerozbil.

[Bystroushaak]

Tak tak.

[Cal]

S prvnim odstavcem vicemene souhlasim.

Jen teda je potreba doplnit, ze "testovani aplikace jako celek" (obvykle zvane "end-to-end") je taky dost drahe - aplikaci je potreba nekam deploynout, inicializovat data pred testem, spustit selenium (popr. jine GUI testovatko), po testu pak zmeny v datech uklidit atp. Takove testy jsou taky casto dost krehke a bezi dost dlouho (v minule praci nam par set takovych testu bezelo cca 6 hodin [testy byly kontinualne optimalizovany]). Jako lepsi kompromis mne vetsinou vychazi API/komponentni testy, ktere odstrani GUI (nejvetsi zdroj problemu), ale stale pochyta vetsinu chyb v logice. Tim nerikam, ze end-to-end testy jsou zbytecne, ale povazuju je spis za doplnek pro otestovani nekolika kritickych happy paths. Urcite se to neda pouzit pro testovani vsech corner casu atp.

V případě refactoringu dává smysl napsat si testy, které ověří konkrétní požadované vlastnosti, které mají refactoring přežít.

No technicky vzato refactoring by nemel mit funkcni zmeny, takze vsechny testy testujici nejaky business use case by mely projit i po refactoringu.

Vyjimkou z toho jsou samozrejme refactoringy ktere meni samotny testovany interface (treba GUI u end-to-end nebo REST API u komponentnich testu).

[Josef Kufner]

No technicky vzato refactoring by nemel mit funkcni zmeny, takze vsechny testy testujici nejaky business use case by mely projit i po refactoringu.

Tady je potřeba definovat, co jsou ty funkce a kde by ty funkční změny mohly nastat. To se hodí definovat právě testy.

[Bystroushaak]

+1

[Cal]

Souhlasim. Ale tu definici neudelate unit testy, ale testy vyssi raze (komponentni, end-to-end/functional).

[Bystroushaak]

Podle mě je tohle dělení dost umělé. Neříkám, že se nehodí, ale rozlišovat to jako nějakou ostrou hranici mi přijde jako neodůvodněné.

[Cal]

Ty hranice ostre moc nejsou, ale nektere principy zustavaji - napr. ze unit testy testuji male jednotky kodu a jsou izolovane od okoli (napr. zadny sitovy traffic).

Takova klasifikace ma sve vyhody - u unit testu muzes ocekavat rychly beh, mas "zaruku", ze testy nemaji nejake externi zavislosti na prostredi. Neni potreba zadny cleanup i kdyz katastroficky skapou. Jsou reprodukovatelne atp.

[Bystroushaak]

Kdyz se podivam treba na takove kontrolery nebo servisni tridy vicevrstve aplikace, tak ony takovou pekne enkapsulovanou logiku nemaji - vetsinou jen volaji nizsi vrstvy typu uloz neco do databaze. Test pak vypada tak, ze namokujes vsechny ty zavislosti a jen poslouchas jestli tohle a tohle bylo volane s takovym parametrem. Ve vysledku nic zajimaveho netestujes. Skutecnou chybu takove testy malokdy odhali. Naopak produkuji spoust false negatives kdyz se rozbiji pri kazdem refactoringu.

Netvrdím, že to chce 100% pokrytí, ale říct že "testy obecne velky vyznam nemaji"? To právě vůbec nesedí na mojí zkušenost, kde na nutnost mít nějakou formu testy (ať už unit, nebo integračních) narážím každou chvíli právě i na vlastních projektech. Například teď si dělám toy programovací jazyk a bez testů bych byl upřímně úplně v háji.

Na refactoring se mi daleko vic osvedcily integracni/komponentni/API testy.

Záleží asi jak to definuješ. Já se většinou snažím všechno co není moc drahé pokrýt unittesty, což je nejspíš už špatně a mělo by to být v integračních.

[rADOn]

…Kdyz se podivam treba na takove kontrolery nebo servisni tridy vicevrstve aplikace, tak ony takovou pekne enkapsulovanou logiku nemaji - vetsinou jen volaji nizsi vrstvy typu uloz neco do databaze. Test pak vypada tak, ze namokujes vsechny ty zavislosti a jen poslouchas jestli tohle a tohle bylo volane s takovym parametrem. Ve vysledku nic zajimaveho netestujes.

Presne takovyhle testy mi nutil jeden byvaly kolega na "testovani" db vrstvy. Vysledek byl ze v CIcku nam hezky svitilo 100% pokryti a v kodu byly skolacky chyby, vcetne nejhrubsiho sql injection. Takovy testy jsou opravdu horsi nez zadny.

[Pavel Křivánek]

Vidíte problematiku testování v jiném kontextu. Já programuji ve Smalltalku, který nepoužívá statickou typovou kontrolu. Dokud se kód neotestuje, lze se o jeho správnosti jen domýšlet. To znamená, že se v nějaké formě testuje téměř vždy. Jakmile se to dělá, je jen přirozené se to hned snažit zautomatizovat. Ostatně první xUnit byla vytvořena právě pro Smalltalk.

Ve Smalltalku se používá jiný přístup k vývoji programů, což plyne z jeho fundamentálních odlišností. Snažit se věci, co tam fungují, bezhlavě naroubovat jinam, nevede k ideálním výsledkům.

Samozřejmě i tam jsou věci, které se testují špatně, typicky UI. Ale i tak často (a netvrdím, že vždy) stojí za to do testů investovat. Pokud se jedná o produkt, který je potřeba dlouhodobě rozvíjet, vyplatí se to. Co až někdo vydá novou verzi Pythonu? Co až bude potřeba váš program překompilovat na jiné výrazně odlišné architektuře s jinou endianitou? Vezmete váš program a řeknete, že by měl fungovat? Co když ten program budou muset převzít co nejrychleji úplně jiní vývojáři a rychle do něj doplnit nějakou funkcionalitu?

Naučit se testovat software co nejúčinněji s minimálními dodatečnými náklady, je dovednost k nezaplacení. Podle vás jednotkové testy nejsou způsob, jak toho dosáhnout, což je pravda, ale ne univerzální. Dle mých zkušeností v tom hrají velmi důležitou roli.

[JS1]

Z meho pohledu jsou testy vlastne jen castecnou reimplementaci puvodniho programu. Kdyby totiz testy pokryvaly 100% vsechnu funkcionalitu, pak to znamena, ze testy se chovaji stejne jako testovany program na kazdem moznem vstupu. (Typicky jsou ovsem testy jen reimplementaci programu na nejakou vhodnou podmnozinu - muze byt i nekonecna - vstupu.)

Z tohoto pohledu dava smysl podivat se na celou vec dualne, tj. muzeme pouzit testy k overeni programu, ale take program k overeni testu, jak se to deje v tomto pripade.

Na zaver blazniva myslenka. V podstate uplne idealnim zpusobem testovani by bylo napsat program nezavisle vicekrat a pak otestovat na ruzne vstupy. Ale pokud uvazime analogii se samoopravnymi kody, takovy pristup je podobny opakovacimu kodu. To je ovsem dost neefektivni kod, lze si tedy polozit otazku, co by bylo analogem efektivnejsich kodu ve vyse uvedene analogii testovani SW? (Pravdepodobne nejaky podivny hybrid, kde lze casti programu systematicky vymenovat za testy a naopak.)

[Dirka]

Procetl jsem diskuzi a opravdu nechapu vyvojare, co tu tvrdi, ze lze psat bez unit testu. Mel jsem v praci kolegu co tvrdil, ze dokaze psat bez chyb, fajn dal mi svou fci, ja mu ji rozbil. On tvrdil, ze jen potrebuje vic casu, dal jsem mu ho a opet jsem mu to rozbil. Proste bez chyb psat nelze.

Nicmene je treba si uvedomit, ze unit test je nekde na spodku pyradmidy, nad tim jsou napr integracni testy a pak treba GUI/end user testy. Vse je o spravne kombinaci vsech techto vrstev, ani jedna sama o sobe nemuze zarucit fcnost aplikace/produktu, je to o spravnym mixu a ten je proste o zkusenostech.

Ja osobne zastavam nazor, ze kazdej nove nalezenej bug si zaslouzi formu testu (na spravne urovni), tzn uz nikdy vice regrese! Toto ma vyhodu, ze mame na projektu jistotu, ze neduplikujeme veci, proste prosel bug k zakaznikovi = musime rozsirit testy. V dlouhodobym hledisku ocenite tento pristup, az budete napr silne refaktorovat (zazil jsem a neni nad to, kdyz vyvojar muze posilat co chce a testy mu hned reknou = takto ne), ale zejmena to oceni vasi zakaznici.

A jen noticka na konec - zadnej sw neni bez bych, jen totalni kokot tomu veri; chybam je treba kontrolovane predchazet.

[Martin Tůma]

Procetl jsem diskuzi a opravdu nechapu vyvojare, co tu tvrdi, ze lze psat bez unit testu.

Vidíte, já zase opravdu nechápu někoho, kdo sem napíše příspěvek zcela popírající realitu, když "tisíce důkazů sporem" má doslova na dosah ruky...

[Dirka]

??? Co kdyby si to rozved? A prosim nevykej mi.

[JS1]

Precti si diskusi.. Mas tu spoustu prikladu veci, ktere funguji a nemaji unit testy.

[Dirka]

No jo, jenze pokud sis precetl celej muj prispevek, pisu o vice typech testu a jejich vhodne kombinaci. A ne, opravdu neverim, ze existuje projekt, kterej dava smysl bez jakychkoliv testu, to je naivni predstava.

[Martin Tůma]

Na jeden takový, který používají desetitisíce lidí už tu odkaz je. A existují i takové, které používají miliony lidí a žádné testy* nemají, například 7Zip. To že se váš korporátní intergalaktický, 15 services, a já nevim co ještě systém nedá udržovat bez automatizovaných testů ještě zdaleka neznamená, že se tak nedá udržovat žádný smysluplný SW.

* Bavíme se tedy o nějakých automatizovaných testech, které se pravidelně používají, ne o "testech", že to lze zkompilovat a spustit, bez těch se asi opravdu žádný SW neobejde...

[Bystroushaak]

A existují i takové, které používají miliony lidí a žádné testy* nemají, například 7Zip.

Nepřijde mi jako zrovna dobrá ukázka, vzhledem k počtu kritických chyb. Možná by nebylo do věci s tím testováním začít. Přitom to zrovna vypadá na testy odhalitelné chyby:

Incorrect initialization logic of RAR decoder objects in 7-Zip 18.03 and before can lead to usage of uninitialized memory, allowing remote attackers to cause a denial of service (segmentation fault) or execute arbitrary code via a crafted RAR archive.

Insufficient exception handling in the method NCompress::NRar3::CDecoder::Code of 7-Zip before 18.00 and p7zip can lead to multiple memory corruptions within the PPMd code, allows remote attackers to cause a denial of service (segmentation fault) or execute arbitrary code via a crafted RAR archive.

...

[Martin Tůma]

Právě naopak, to je úplně ta nejlepší ukázka. Je na ní vidět, že milionům lidí je úplně jedno, jestli má ten SW testy, které by (v ideálnim případě) odhalily jedno CVE ročně. Protože jednak existence CVE zdaleka neznamená existenci reálného útoku a hlavně drtivá většina lidí by se stejně s takovým archivem nikdy nesetkala. Ano, lze to dělat i líp, ale pro tu hromadu uživateů je to zcela irelevantní.

Nic ti ale samozřejmě nebrání, ty testy napsat, nebo je zaplatit, pokud s tím ty máš problém. Autorovi se to zřejmě ne(vy)|(za)platí.

[Bystroushaak]

Je na ní vidět, že milionům lidí je úplně jedno, jestli má ten SW testy, které by (v ideálnim případě) odhalily jedno CVE ročně.

Kritické CVE, vedoucí k automatickému spuštění libovolného kódu. To je průser jak vrata. Jeden ten CVE jsem kdysi studoval a nebylo to nic hypotetického. A hádej co, měli jsme ho volně zneužitelný v produkčním prostředí.

[Martin Tůma]

A napsali jste pro 7Zip ty testy, nebo jste zaplatili jejich vývoj? Přešli jste na jiný SW (jaký?). Pokud ne, tak to ani pro vás očividně nebyl zas tak podstatný problém...

[Bystroushaak]

A napsali jste pro 7Zip ty testy, nebo jste zaplatili jejich vývoj? Přešli jste na jiný SW (jaký?). Pokud ne, tak to ani pro vás očividně nebyl zas tak podstatný problém...

Kdybych si mohl určovat co budu dělat jen tak jak se mi zachce a někdo by mi za to pořád platil stejně, jako když dělám práci, tak bych byl klidně ochotný ty testy napsat.

[Martin Tůma]

Takže ty testy ti nikdo nezaplatí, zadarmo je dělat nebudeš ale chceš po jiných aby je oni dělali zadarmo. Ano, v takovém světě, kde unit testy jsou za peníze někoho jiného, opravdu nedává smysl je nemít...

[deda.jabko]

Ano, v takovém světě, kde unit testy jsou za peníze někoho jiného, opravdu nedává smysl je nemít...

To je velice kratkozraky pohled.

Testy pouzivam i na mensich osobnich projektech, protoze si prilis vazim sveho casu. Misto toho, abych jednou udelal nejake ad hoc testovani, kterym stejne na nejaky extrem zapomenu, tak ten cas radeji venuju napsani testu, ktere muzu pouzit kdykoliv a za par sekund (nebo setin sekund) si muzu overit, ze vsechno funguje, jak ma, a nic jsem nerozbil. Navic, narozdil od ad hoc testovani code coverage dokaze navest, co je potreba jeste overit a co neni testovane.

Proc bych pri nejake zmene mel testy sam opakovat (nebo nedej boze najimat testera), kdyz muzu nechat pocitac, at to udela sam?

Testy nejsou cisty naklad, jak se tu snazis tvrdit, ale investice, ktera se vrati po urcitem case. Casto hned pri dalsi uprave programu.

[Michal Kubeček]

tak ten cas radeji venuju napsani testu, ktere muzu pouzit kdykoliv a za par sekund (nebo setin sekund) si muzu overit, ze vsechno funguje, jak ma, a nic jsem nerozbil

Tak to bych chtěl (na nějakém netriviálním příkladu) vidět. Ale spíš se obávám, že prostě jen přeháníte.

[deda.jabko]

Ale spíš se obávám, že prostě jen přeháníte.

Ja jsem si myslel, ze na tento typ autisticke interpretace textu jsou tu odbornici jini.

Tak to bych chtěl (na nějakém netriviálním příkladu) vidět.

Uz nekolikrat se mi stalo, ze zmena v jedne casti kodu rozbila kod v casti, kde jsem to absolutne necekal (a rucne bych to asi netestoval) a byl by z toho asi prusvih, kdyz by to proslo do produkce.

[Michal Kubeček]

Ja jsem si myslel, ze na tento typ autisticke interpretace textu jsou tu odbornici jini.

Co je autistického na upozornění, že tvrzení, že píšete testy, které ověří, že všechno funguje jak má a nic jste nerozbil, jsou silácké řeči, které mají k realitě hodně daleko?

Uz nekolikrat se mi stalo, ze zmena v jedne casti kodu rozbila kod v casti, kde jsem to absolutne necekal (a rucne bych to asi netestoval) a byl by z toho asi prusvih, kdyz by to proslo do produkce.

O tom ale řeč nebyla. Já bych prostě jen chtěl vidět, jak píšete ty testy, které odhalí jakoukoli chybu.

A nebo raději přiznejte, že jste se nechal unést a to, co jste napsal, není pravda. Že unit testy, stejně jako kterékoli jiné, odhalí jen určité konkrétní chyby, ale zdaleka ne všechny.

[deda.jabko]

Co je autistického na upozornění, že tvrzení, že píšete testy, které ověří, že všechno funguje jak má a nic jste nerozbil, jsou silácké řeči, které mají k realitě hodně daleko?

Uznavam obzalobu v plne mire a doznavam se k tomu, ze jsem se nechal unest a uzil jazyka jako bezny obcan, aniz bych si uvedomoval, ze jsou mezi nami osoby, ktere slova vykladaji pouze v jejich uzkemu vyznamu, a proto jsem se dopustil jejich zmateni, cehoz je mi hluboce lito a priste se tohoto konani nedopustim.

Staci to takto?

Že unit testy, stejně jako kterékoli jiné, odhalí jen určité konkrétní chyby, ale zdaleka ne všechny.

To je snad zjevne kazdemu [čti téměř každému]. Dodavam, ze to neni argument pro jejich nepouzivani.

[Bystroushaak]

Takže ty testy ti nikdo nezaplatí, zadarmo je dělat nebudeš ale chceš po jiných aby je oni dělali zadarmo. Ano, v takovém světě, kde unit testy jsou za peníze někoho jiného, opravdu nedává smysl je nemít...

Testy mi samozřejmě zaměstnavatel / zadavatel běžně platí na mých/jeho projektech, ale opravdu mi je nebude platit na 7zipu. Nemůžu říct, že bych se mu divil.

[Martin Tůma]

Psal si, že ten 7zip byl součástí vašeho projektu:

Kritické CVE, vedoucí k automatickému spuštění libovolného kódu. To je průser jak vrata. Jeden ten CVE jsem kdysi studoval a nebylo to nic hypotetického. A hádej co, měli jsme ho volně zneužitelný v produkčním prostředí.

[Bystroushaak]

Bylo to součástí relativně malé komponenty. Na pointě to nic nemění.

[Martin Tůma]

Takže systém kompromitovaný skrze "relativně malou komponentu" je v pohodě, narozdíl od systému kompromitovaného skrze nějakou "velkou" komponentu?!

Jinak ano, pointa je stejná - vaše systémy mají otestovanou pouze nepatrnou část, protože na to, aby byly skutečně kompletně otestované v reálném světě nejsou peníze a/nebo čas. To že si napíšete testy pro malou vrchní část, která spojuje dohromady násobně větší množství kódu ve spodu (od OS až po aplikační knihovny), který testy nemá a tváříte se, že "bez testů nelze psát", je jenom pokrytectví.

[Bystroushaak]

Takže systém kompromitovaný skrze "relativně malou komponentu" je v pohodě, narozdíl od systému kompromitovaného skrze nějakou "velkou" komponentu?!

Přednesl jsem to managementu, ten s tím byl seznámen a rozhodl dle svého uvážení vyřešit potenciální problémy jinak (sandboxem).

Jinak ano, pointa je stejná - vaše systémy mají otestovanou pouze nepatrnou část, protože na to, aby byly skutečně kompletně otestované v reálném světě nejsou peníze a/nebo čas. To že si napíšete testy pro malou vrchní část, která spojuje dohromady násobně větší množství kódu ve spodu (od OS až po aplikační knihovny), který testy nemá a tváříte se, že "bez testů nelze psát", je jenom pokrytectví.

Myslím, že „bez testů nejde psát“ jsem nikdy neřekl, pouze jsem poukázal na natolik vyšší chybovost, že se to ani neumím představit, jak by mohl větší projekt fungovat bez nich a nezměnit se v peklo už jen kvůli refactoringu a práci v týmu.

Tvůj postoj mi přijde čím dál víc irelevantní - původně jsem si myslel, že máš třeba co říct k věci, třeba nějakou lepší techniku, nebo nějakou metodiku, která povede k lepším výsledkům. S tím jak diskuze postupuje mi ale čím dál víc přijdeš jako kolovrátek co pořád dokola hejtuje cargo cult testů. Taky uznávám že unittesty nejsou silver bullet, jen mi nepřijde jako hodnotné je kvůli tomu zavrhovat.

Testy samozřejmě neřeší všechny problémy, které mohou nastat (ostatně co kdy řeší?). To je asi jasné každému, kdo je kdy prakticky používal. Přesto podle mého názoru významně, řekl bych dokonce blahodárně snižují velikost prostoru chyb. Pokud ti to přijde jako pokrytectví, tak mi další diskuze přijde jako plané zabíjení času.

[johnyK]

co pořád dokola hejtuje cargo cult testů

ja nejsem v zadnem pripade advokat pana Tumy i kdyz s nim vpodstate souhlasim. Feynman, kdyz kritizoval ten cargo-cult, tak nabadal, aby vedci, inzenyri, lekari byli proste kazdy den ochotni a pripraveni prehodnotit sve zazite nazory, postupy. To u vas nepozoruji (a u znacne casti zde obdobne diskutujicich) a proto se nedivim, ze pan Tuma jeste neni z vasich odpovedi zcela uspokojen.

Pozoruji, ze znacna cast populace (nebo diskutujicich zde na abcl) je ochotna prehodnotit sva stanoviska teprve tehdy, az nekdo predstavi 'lepsi' postupy, metodiky, reseni. Do te doby jsou ochotni pouze priznat, ze jimi preferovany postup neni 'samozrejme to absolutni reseni', ale dokud nekdo neprinese neco prukazne lepsiho, tak se u toho stavajiciho zustane.

Tento muj prispevek nemel ted vyresit tu problematiku tech unit-testu, jen jsem chtel z meho pohledu upozornit na to, proc se ta diskuze toci dokola a tocit bude, protoze ani pan Tuma, a ani napr. ja nedokazeme zde na nekolika radcich predlozit to 'lepsi' reseni.

[JS1]

Mas pravdu.

Kazdy ma ty zkusenosti trochu jine. Ja se treba vys malicko neshodnu s deda.jabko, prestoze si jeho nazoru (i politickych) vesmes vazim. A mozna ze to co dela je i spravnejsi v jeho situaci.

Hodne je to videt na dynamicky vs. staticky typovanych jazycich. Ja treba za svuj zivot uz ten postoj nejmin dvakrat prehodnotil (prosel jsem si jako oblibeny jazyk BASIC, assembler, Pascal, C, C++, Python, Common Lisp, Haskell..).

[deda.jabko]

Kazdy ma ty zkusenosti trochu jine. Ja se treba vys malicko neshodnu s deda.jabko, prestoze si jeho nazoru (i politickych) vesmes vazim. A mozna ze to co dela je i spravnejsi v jeho situaci.

Napodobne.

Ja treba za svuj zivot uz ten postoj nejmin dvakrat prehodnotil (prosel jsem si jako oblibeny jazyk BASIC, assembler, Pascal, C, C++, Python, Common Lisp, Haskell..).

Ja si taky prosel celou radku jazyku na ulohach jednodussich i slozitejsich, coz ze me s postupem casu udelalo spis pragmatika a snazim se volit reseni, ktere v dane situaci vychazi nejlip.

Pujdu s kuzi na trh a zacnu se bavit trochu konkretneji, protoze doposud diskuze probihala v abstraktni rovine, ktera zahrnoval SAT-solver i jadro operacniho systemu, coz jsou uplne jine typy aplikaci at uz podstatou ci rozsahem.

Pred lety jsem zacal programovat knihovnu MyJIT pro generovani strojoveho kodu za behu, protoze jsem ji proste potreboval.

Svym rozsahem to je spis mensi projekt (20k LOC) v cistem C, ale uz v rane fazi vyvoje (a pouzivani) se ukazalo, ze (unit) testy jsou nezbytne, protoze hledat chyby az pri pouziti v cilove aplikaci bylo peklo. Takze projekt ma aktualne 10k LOC (prevazne) unit (a integracnich) testu.

Diky tomu, ze jsem venoval nemalo casu implementaci testu, bylo nasobne jednodussi implementovat podporu pro nove architektury. Nekolikrat se mi stalo, ze jsem opravoval chybu na nejakem citlivem miste, napr. alokace registru na AMD64, a ze se mi vysledek projevil nekde uplne jinde, protoze jsem si neuvedomil, ze treba na SPARC je nejaka odlisnost, na kterou jsem zapomnel.

V zacatcich jsem taky byl frajer a kaslal na 100% pokryti testy, s tim, ze jsem si rikal: "Tyto funkce stejne nikdy nepouziju a vypadaji dobre". Pak mi zacali lidi hlasit, ze se jim neco chova divne, a jake bylo prekvapeni, ze ty funkce, co vypadaji dobre a stejne je nikdo nepouziva, maji v sobe chybu.

Tak a ted pojdme diskutovat, jak jsem mel/mohl/muzu zajistit lepsi kvalitu kodu.

Napad JS1 pouzit Haskell v tomto pripade pada, protoze jsem chtel/potreboval byt co nejbliz zeleza, stejne jako dalsich par lidi, co tu knihovnu pouziva. (Slusi se dodat, ze to ve zdejsi diskuzi proti jednotkovym testum byl ale nejrelevantnejsi navrh.) Tato varianta v praxi casto pada.

JohnyK navrhuje prehodnotit postoje, ale uz nauvadi jak.

Pan Tuma oznacuje systematicky unit testy za cargo-cult, coz se nejak rozchozi se zkusenosti mou (i jinych), pricemz nenabizi jinou alternativu, jak zajistit kvaltinejsi. Navic, oznaceni cargo-cult me v tomto kontextu urazi, protoze po mnoha zkusenostech moc dobre vim, proc chci mit testy a vysoke pokryti kodu testy. Zkratka, uz jsem se za ty roky mockrat spalil.

Rad si vyslechnu alternativy a rad si je vyzkousim, protoze me tato problematika opravdu zajima, ale zatim to je od nekterych takovy bez obsazny hate.

[Martin Tůma]

Mě zase uráží, že se mi tady neustále někdo snaží podsouvat něco, co vůbec netvrdím. Unit testy rozhodně systematicky neoznačuju za cargo-cult. Co dělám je to, že za cargo kult označuji tvrzení typu:

opravdu nechapu vyvojare, co tu tvrdi, ze lze psat bez unit testu

které se tu objevují. Že existují projekty, kde unit testy dávají velice dobrý smysl jsem tu psal. MyJIT může samozřejmě patřit mezi ně a odhadoval bych, že asi i patří. Jednak je to něco, co se bude dobře tímto způsobem testovat a dále je to z podstaty věci dost náchylný k zásadním (a špatně debugovatelným) problémům za běhu.

Nakonec bych chtěl již po několikáte zopakovat, že se nesnažím nabízet nějaké magické lepší řešení dosažení kvality SW, ale pouze poukazuju na to, že jsou mraky projektů, kde provedli zcela racionální rozhodnutí věnovat místo na unit testy zdroje na pro daný projekt nějakou užitečnější činnost.

[deda.jabko]

Mě zase uráží, že se mi tady neustále někdo snaží podsouvat něco, co vůbec netvrdím.

Zacinas uhybat. Psal jsi:

Pro většinu SW není, slovy klasika, "testování zasazeno do reálných ekonomických rámců"

Ano, existují kategorie SW, kde takto důkladné testování má svůj smysl (kritické řídící systémy, systémy přes které tečou velké peníze, ...), ale takových je naprostá minorita.

Sorry jako, ale nejak nechapu, cim se MyJIT vymyka jinym (klidne i hobby projektum), ze muze byt zarazen mezi kriticke ridici systemy, financni systemy, atp. Chces rict, ze neni kriticky system, kde mohou vznikat skody, tak nema cenu se systematicky starat o kvalitu jeho kodu?

Nakonec bych chtěl již po několikáte zopakovat, že se nesnažím nabízet nějaké magické lepší řešení dosažení kvality SW

Me nezajima nejake magicke reseni, me zajima proste najek jine reseni, ktere nabizis. Z druhe strany by me zajimaly ty projekty, kde se utopily zbytecne clovekohodiny na psani testu. Protoze mi to prijde ponekud jako slamenny panak.

[Martin Tůma]

Mě zase uráží, že se mi tady neustále někdo snaží podsouvat něco, co vůbec netvrdím.

Zacinas uhybat. Psal jsi:

Pro většinu SW není, slovy klasika, "testování zasazeno do reálných ekonomických rámců"

Ano, existují kategorie SW, kde takto důkladné testování má svůj smysl (kritické řídící systémy, systémy přes které tečou velké peníze, ...), ale takových je naprostá minorita.

Nevidím tady žádný rozpor. Trojtečka na konci běžně znamená "a další", kam bych zrovna MyJIT klidně zařadil.

Sorry jako, ale nejak nechapu, cim se MyJIT vymyka jinym (klidne i hobby projektum), ze muze byt zarazen mezi kriticke ridici systemy, financni systemy, atp.

Opravdu máš pocit, že JIT compiler je zcela běžný typ projektu, kterých jsou statisíce? Mě to tedy přijde jako dost specializovaná věc, která může být použita v některých typech "důležitého" SW. Asi to není tak kritické jako běžný compiler, ale běžná věc to IMHO teda není...

Chces rict, ze neni kriticky system, kde mohou vznikat skody, tak nema cenu se systematicky starat o kvalitu jeho kodu?

Ne. Že je implikace to samé jako ekvivalence jsem nikdy netvrdil.

Me nezajima nejake magicke reseni, me zajima proste najek jine reseni, ktere nabizis.

Já se ale nesnažím nabízet řešení zvyšující kvalitu. Já nabízím řešení snižující cenu.

Z druhe strany by me zajimaly ty projekty, kde se utopily zbytecne clovekohodiny na psani testu. Protoze mi to prijde ponekud jako slamenny panak.

Něco jako toto?

[deda.jabko]

Nevidím tady žádný rozpor. Trojtečka na konci běžně znamená "a další", kam bych zrovna MyJIT klidně zařadil.

A nejak jsi mi neodpovedel, v cem se to lisi a cim si MyJIT vyslouzilo byt zarazeno do te trojtecky mezi kriticke ridici systemy, systemy pres ktere tecou velke penize. Obzvlast, kdyz takovych projektu, ktere si to zaslouzi, je podle tebe naprosta minorita.

Jen dodam, ze to puvodne vzniklo jako soucast experimentalniho prekladace, ktery nikdy nebyl zamyslen pro produkcni nasazeni.

Chces rict, ze neni kriticky system, kde mohou vznikat skody, tak nema cenu se systematicky starat o kvalitu jeho kodu?

Že je implikace to samé jako ekvivalence jsem nikdy netvrdil.

Nasledovane:

Já se ale nesnažím nabízet řešení zvyšující kvalitu. Já nabízím řešení snižující cenu.

Uff. Ok, takze vsichni, co nedelaji kriticke systemy, systemy pres ktere tecou velke penize, nebo nejsou zrovna experimentalni prekladac, mohou kaslat na kvalitu kodu, protoze to pak bude levnejsi.

Staci, dalsi diskuze uz mi prijde zbytecna.

Něco jako toto?

To uz je na urovni trolleni.

[Martin Tůma]

Jak už jsem psal, k těm třem tečkám bych řadil i kompilátory a k těm má JIT compiler dost blízko. MyJIT možná vznikl jako část experimentálního překladače, ale vzhledem k tomu, že píšeš, že ho dnes používají jiné projekty, které hlásí chyby, tak dnes už bych ho zase jako tak experimentální věc neviděl. Navíc předpokládám, že ty testy byly reakcí právě na reálné využití.

Jedna věc by mě ale zajímala - skutečně považuješ MyJIT v současné záplavě appek pro mobily, webových aplikací a podobných projektů za zcela obyčejný projekt, nebo je to jenom účelové tvrzení, aby si mohl tvrdit, že dle mého názoru pro něj tedy unit testy nejsou potřeba? Protože pokuď je a) správně, vysvětlovalo by to, proč se neshodneme ani na tom, co ten druhý vlastně tvrdí. Reálný svět pro každého z nás zkrátka vypadá zcela jinak.

[deda.jabko]

Navíc předpokládám, že ty testy byly reakcí právě na reálné využití.

Psal jsem:

uz v rane fazi vyvoje (a pouzivani) se ukazalo, ze (unit) testy jsou nezbytne, protoze hledat chyby az pri pouziti v cilove aplikaci bylo peklo

Nebo ty bys chtel pouzivat software, ve kterem jsou chyby? Vim, ... ano, pokud to bude levne.

v současné záplavě appek pro mobily, webových aplikací a podobných projektů

Co delaji jini, pro me neni podstatne.

skutečně považuješ MyJIT ... za zcela obyčejný projekt

V podstate jej povazuji za min nez obycejny. Domena, kterou to resi sice vypada slozite, ale ze softwarove-inzenyrskeho hlediska je to API asi o 20 funkcich a cca 100+ makrech, ktere lze taky chapat jako funkce. Takze opravdu nic neobycejneho. Bezne projekty (treba v Jave) maji verejne API mnohem kosatejsi.

Takze moje otazka porad zni, jak se pozna projekt, kde testy davaji smysl a odkdy je jedno, kdyz v projektu zustanou chyby?

[Martin Tůma]

Jakou relevanci má tvoje označení MyJIT za "méně než obyčejný", když co dělají jiní tě nezajímá? Definice slova obyčejný jaksi vychází z toho, co dělají ostatní...

Denně používám spoustu software, ve kterém jsou chyby. Ale na většinu z nich nikdy nenarazim, takže pro mě nejsou podstatné. Většina SW například obsahuje chyby při načítání neplatných vstupů . Ostatně Dirka například tento fakt zcela logicky použil při svém, zatím neúspěšném (nerad bych, aby to vzdal tak rychle), pokusu ukázat, že GPXSee je kopa sraček, protože nemá unit testy. A pokuď tomu věnuje skutečně nějaké netriviální úsilí, tak nějakou takovou chybu časem určitě nalezne. Drtivé většině uživatelů GPXSee bude ale taková chyba zcela ukradená, protože takové vstupy nikdy nepoužijí. Uživatele mnohem víc zajímají jiné vlastnosti, zejména různé pro ně důležité "features".

Čímž se dostávám k odpovědi na tvojí poslední otázku a tou je ono Klausovo oblíbené slovíčko trh. Ten totiž jako jediný může na tuto otázku odpovědět zcela nestranně. Nicméně, a to si právě místní uctívaču kultu unit testů většinou neuvědomují, trh neposuzuje pouze množství chyb v software, ale také jeho možnosti, cenu a dostupnost (time to market).

[deda.jabko]

Jakou relevanci má tvoje označení MyJIT za "méně než obyčejný", když co dělají jiní tě nezajímá? Definice slova obyčejný jaksi vychází z toho, co dělají ostatní...

Protoze to muzu srovnavat treba s dalsimi (treba i svymi) projekty. Ze softwarove-inzernyrskeho hlediska je to asi 20k LOC v cistem C, zadne exoticke technologie, v podstate one man show, zadne slozite vyvojove tymy, integrace s jinymi technologiemi, aby to vubec jelo, zadny komplikovany setup. Takovych projektu mam nekolik s tim, ze tento jsem udelal OSS s plnou podporou.

Takze moje otazka porad zni, jak se pozna projekt, kde testy davaji smysl a odkdy je jedno, kdyz v projektu zustanou chyby?

Čímž se dostávám k odpovědi na tvojí poslední otázku a tou je ono Klausovo oblíbené slovíčko trh. Ten totiž jako jediný může na tuto otázku odpovědět zcela nestranně.

To je uplna blbost. Prikladem budiz onen MyJIT, prakticky pro nej neexistuje trh, presto unit testy byly nutne, s cim jsi i ty souhlasil.

Nicméně, a to si právě místní uctívaču kultu unit testů většinou neuvědomují, trh neposuzuje pouze množství chyb v software, ale také jeho možnosti, cenu a dostupnost (time to market).

Proc teda uctivaci trhu v teto rovnici systematicky ignoruji naklady na maintenance a opravy chyb, ktere testy vyrazne snizuji? To nemluvim o spatne vycislitelnych hodnotach, jako je ztrata reputace, resp. klientu, kteri kvuli chybam odejdou jinam.

[Martin Tůma]

Tak jistě, vyberu-li si vhodnou podmnožinu projektů, tak v té podmnožině může být běžné ledasco... Ale o tom, co je běžné v rámci celého universa to nevypovídá vůbec nic. A "běžný mezi vlastními projekty", to už je vyloženě vtip. To je něco jako ono Cimrmanovské: "světové proslulosti dosáhl zejména na Kutnohorsku".

To je uplna blbost. Prikladem budiz onen MyJIT, prakticky pro nej neexistuje trh, presto unit testy byly nutne, s cim jsi i ty souhlasil.

Není to blbost, a pro MyJIT trh existuje. Tvoří ho tvůrci JIT compilerů a MyJIT má dokonce i přímou konkurenci na tomto trhu - GNU lightning. Je to možná trh malý, ale trh to zcela jednoznačně je.

Proc teda uctivaci trhu v teto rovnici systematicky ignoruji naklady na maintenance a opravy chyb, ktere testy vyrazne snizuji? To nemluvim o spatne vycislitelnych hodnotach, jako je ztrata reputace, resp. klientu, kteri kvuli chybam odejdou jinam.

V tom je právě ten hlavní rozdíl mezi námi. Já netvrdím, že nemá smysl mít unit testy u žádného projektu. Pokuď tyto uváděné hodnoty převýší náklady, tak proti tomu nemám žádné námitky. Vy proti vašemu dogmatu nepřipouštíte žádné alternativy.

[deda.jabko]

Tak jistě, vyberu-li si vhodnou podmnožinu projektů, tak v té podmnožině může být běžné ledasco...

Jasne jsem ti popsal charakteristiku projektu. Takze asi 20k LOC v cistem C, zadne exoticke technologie, v podstate one man show, zadne slozite vyvojove tymy, integrace s jinymi technologiemi, aby to vubec jelo, zadny komplikovany setup. Jak se to teda vymyka "beznym projektum"? Nejeden e-shop v php je proti tomu komplexni aplikace.

Není to blbost, a pro MyJIT trh existuje. ... Je to možná trh malý, ale trh to zcela jednoznačně je.

Kdybych to programoval sam pro sebe, coz jsem programoval, tak bych ty testy musel delat tak jako tak. Takze cely trh bych tvoril jen ja, ja sam, coz jsem tvoril. Takze jsem se stal trhem. Ty to uvahy uz sklouzavaji na uroven Ivana Noveho...

Pokuď tyto uváděné hodnoty převýší náklady, tak proti tomu nemám žádné námitky. Vy proti vašemu dogmatu nepřipouštíte žádné alternativy.

Co mi to podsouvas za slameneho panaka? Ja jsem nikde nic takoveho netvrdil. Na druhou stranu jsem jeste takovy projekt nevidel, a kdyz jsem se ptal na priklad tech projektu, kde testy prevysily naklad, tak jsi vytahl nejakou hovadinu na par radku kodu, ktera opravdu nejde oznacit ani jako projekt, ani jako aplikace. Vlastne je to mlaceni stejneho slamenneho panaka.

[Martin Tůma]

Ok, zdá se, že to tedy myslíš vážně. V tom případě, jak už jsem psal o několik úrovní výše, opravdu nemá cenu toto vlákno dále prodlužovat. Pokuď se neshodnem ani na tak základní věci, jestli je JIT generátor ASM z hlediska veškerých SW projektů zcela běžný projekt, je zhola nemyslytelné, abychom došli k nějaké shodě v případě tak kontroverzního tématu jako jsou unit testy.

[deda.jabko]

Pokuď se neshodnem ani na tak základní věci, jestli je JIT generátor ASM z hlediska veškerých SW projektů zcela běžný projekt

Pokud nejsi schopen abstrahovat od konkretni domeny a podivat se na projekt ciste ze softwarove-inzenyrskeho hlediska, pak ta diskuze opravdu nema smysl.

[xxx]

Nemyslim si, ze zrovna testy zvysi kvalitu kodu. Kdyz pises nekvalitni kod, pak pises nekvalitni testy (coz je taky kod), a obavam se, ze pokud se nestane zazrak, pak budes mit stale nekvalitni kod. Sice v nem bude min chyb (s kvalitnimi testy jeste min), ale to z nej jeste porad kvalitni kod nedela.

[deda.jabko]

Nemyslim si, ze zrovna testy zvysi kvalitu kodu.

Otazkou je, co chapes pod pojmem kvalita kodu. A ja v tom chapu i mnozstvi skrytych chyb. A pokud nejsi guru jako Radek Hulan, ktery denne pise megabyty precizne odladeneho objektoveho kodu, tak jsi urcite schopen priznat, ze kazdy programator dela chyby a testy jsou prostredek, jak je odhalit.

Je to asi tak, kdyz pises treba oficialni text, taky si to po sobe prectes, jestli neudelals nejakou chybu, i kdyz normalne gramaticke nebo stylisticke chyby nedelas, ale co kdyby...

pak pises nekvalitni testy (coz je taky kod)

To je hodne podivny osly mustek. Testy jsou sice kod, ale naprosto trivialni, ktery nema obsahovat zadnou logiku, tj. jsou to tvrzeni typu "kdyz zavolam funkci s temito parametry, dostanu tento vysledek" nebo "kdyz zavolam metodu, zmeni se objekt tak a tak".

Nemyslim si, ze zrovna testy zvysi kvalitu kodu.

Ja si myslim opak, uz jsem to tu psal, viz.

Tim, ze chces mit kod testovatelny, ma to neprimy vliv i na strukturu kodu.

1. Testovatelnost kodu te nuti psat kod proti obecnym rozhranim, ne proti konkretnim objektum.
2. Testovatelnost te nuti vytvaret kod, kde nejsou tesne svazane moduly a komponenty.
3. A v neposledni rade, programatori maji tendenci uvazovat jen nad hlavni vetvi kodu, ktera se provadi, kdyz vsechno funguje je jak ma. V momente, kdyz zacnes resit testy, primeje te to resit i okrajove pripady.

Ergo, i pokud mas tendenci psat nekvalitni kod (co do struktury ci navrhu), unit-testy te neprimo tlaci ke kvalitnejsimu kodu.

[xxx]

Ne pisu jen 20 tisic radek kvalitniho kodu za tyden jako Ponkrac. Co tvrdim je, za testy maji z pohledu kvality kodu vliv jen na pocet chyb.

Jestli bych neco u testu oznacil za cargo cult, tak prave to co pises #45 a v bodech (1 - 3). Nekdo nekdy videl kavalitni kod s testy a od te doby si mysli, ze za to mohly prave testy. Ja si spis myslim, ze kdyz nepises kvalitni kod a pises testy, pak misto zlepsovani kodu, spis ojebavas ty testy (protoze ani nevis jak vlastne ten kvalitni kod napsat).

Jen to prosim neber absolutne, protoze urcite uz se i nekdo nekdy kvuli testum zamyslel nad tim jaky kod pise.

[Bystroushaak]

Co tvrdim je, za testy maji z pohledu kvality kodu vliv jen na pocet chyb.

Proč jen na počet chyb? Můžeš to nějak rozvést? Já myslím, že existuje přímá souvislost mezi refactorovatelností a unittesty, s tím že pokud je kód pokrytý unittesty, či API testy, tak je lehčí refactorovat a člověk se nemusí bát, že někde něco rozbije. Většinou dokonce když mám refactorovat něco, co nemá žádné testy, tak ty testy předem napíšu.

Myslíš, že tohle nehraje roli na kvalitu kódu?

[Pavel Křivánek]

Docela by mě zajímalo, kolik místních odmítačů unit testů skutečně zkusilo na vlastní kůži TTD alespoň pro část svých projektů, kde to papírově dává smysl. Naopak jsem si jist, že všichni, kdo je zde obhajují, kódu bez testů napsalo určitě spoustu a mají s čím srovnávat. Kdo TTD někdy okusil, těžko by se zdráhal tvrdit, že nezvyšují kvalitu kódu.

[Pavel Křivánek]

ehm, TDD

[deda.jabko]

Kdo TTD někdy okusil

... ten u toho stravil spoustu hodin. ;-] A to nemluvim o OpenTTD, ktera je jeste nasobne lepsi!

[podlesh]

Jasně, a to je vyjádřeno temínem "hipsterský programátor který má na všechno unit testy protože je to dneska cool"?

Je normální že člověk napíše něco co tak nemyslel. Ale v takovém případě je správným postupem sebereflexe, přeformulování a pokus o prevenci nebo urovnání konfliktu. Pokud místo toho ještě své výroky přitvrdím ("double down") a přihodím nějaké osobní urážky, tak jsem prostě efektivně rezignoval na jakoukoliv rozumnou komunikaci. Ve flame war na nějaké nuance není místo, jde o absolutní provady.

[Bystroushaak]

ja nejsem v zadnem pripade advokat pana Tumy i kdyz s nim vpodstate souhlasim. Feynman, kdyz kritizoval ten cargo-cult, tak nabadal, aby vedci, inzenyri, lekari byli proste kazdy den ochotni a pripraveni prehodnotit sve zazite nazory, postupy. To u vas nepozoruji (a u znacne casti zde obdobne diskutujicich) a proto se nedivim, ze pan Tuma jeste neni z vasich odpovedi zcela uspokojen.

Jo, ok. Mám je přehodnotit jak a proč? Že testy nejsou potřeba, protože existují projekty, které je nepoužívají? Když tu argumentuje projektem majícícm několik kritických bugů daných doslova tím, že někdo neotestoval inicializaci RAR knihovny?

Tvrdit že testy jsou k ničemu je jako tvrdit, že je lepší na motorce jezdit bez držení řídítek. Plně uznávám, že je to možné, že to dokonce někomu vyhovuje a že jsou lidi, co si budou pochvalovat, že přitom třeba můžou jíst svačinu. Dokonce uznávám, že někteří to jsou schopni provozovat na každodenní bázi a že to pro ně funguje.

Obhajovat to ovšem jako obecnou praktiku, která ti snad dává nějaké výhody, mi přijde doslova pošetilé. Dvojitě, když je to celé navíc postavené na argumentaci ve stylu "ale to že držíš řídítka ti nijak negarantuje, že se nevybouráš".

Pozoruji, ze znacna cast populace (nebo diskutujicich zde na abcl) je ochotna prehodnotit sva stanoviska teprve tehdy, az nekdo predstavi 'lepsi' postupy, metodiky, reseni. Do te doby jsou ochotni pouze priznat, ze jimi preferovany postup neni 'samozrejme to absolutni reseni', ale dokud nekdo neprinese neco prukazne lepsiho, tak se u toho stavajiciho zustane.

To vážně čekáš, že lidi budou jen tak měnit stanoviska na horší postupy, metodiky a řešení jen tak pro srandu králíkům? Samozřejmě že k tomu všichni chtějí důvod!

[Martin Tůma]

Sorry, ale tohle už je vyloženě demagogie. 7Zip tu byl jako příklad toho, že jedno CVE ročně klidně může být, a ve skutečnosti taky je, milionům uživatelů úplně ukradený, když ten SW zcela vyhovuje jejich potřebám a s reálným problémem, který by to CVE způsobovalo se nikdy nesetkají (stejně tak jako s projevy nějaké jiné chyby, kterou ten SW může mít).

Dále tady nikdo netvrdí, že jsou testy k ničemu. Jediný co se ti tady lidi snaží ukázat je, že to není univerzální, vždy výhodný řešení pro všechny SW projekty.

[Bystroushaak]

Sorry, ale tohle už je vyloženě demagogie. 7Zip tu byl jako příklad toho, že jedno CVE ročně klidně může být, a ve skutečnosti taky je, milionům uživatelů úplně ukradený, když ten SW zcela vyhovuje jejich potřebám a s reálným problémem, který by to CVE způsobovalo se nikdy nesetkají (stejně tak jako s projevy nějaké jiné chyby, kterou ten SW může mít).

Pokud jsi to chtěl uvést jako příklad ignorance lidí, kteří netuší že software co používají je děravá věc, která umožňuje spustit kód každému, kdo jim může poslat soubor, tak to uznávám. Lidi to skutečně používají. Co to má ale dokazovat kromě lidské blbosti mi není úplně jasné.

Jediný co se ti tady lidi snaží ukázat je, že to není univerzální, vždy výhodný řešení pro všechny SW projekty.

Pokud vím, tak nic takového tu nikdo neukázal. Jediné co jsi zde prezentoval je, že existují projekty, které fungují bez testů a dají se považovat za úspěšné. Tedy že testy nejsou podmínka nutná k úspěchu.

Proti tomu jsem vznesl námitku, že i tyhle projekty by z testů mohly těžit, proto jeden z nich (kernel) má různé testovací frameworky a druhý z nich (7zip) by například nemusel mít kritické chyby vzniklé netestováním kódu inicializace rar knihovny.

Na to jsi reagoval tím, že ty testy mám napsat a že je pokrytectví psát testy, co testují jen vlastní vrstvu abstrakce.

V téhle diskuzi jsem několikrát uznal, že testy samy o sobě nevyřeší všechny problémy. Zatím jsem však až na námitku, že někteří lidé testují věci, co testovat třeba není, neviděl přesvědčivý argument, proč by testování nebylo univerzálně a vždy výhodné řešení pro všechny SW projekty. Mé zkušenosti z práce programátora toto jen potvrzují, ať již jde o dynamické jazyky, jako třeba Python, ale i statické a kompilované jazyky, jako třeba Rust.

Jediné, o čem vím, že to může být vhodnější, než testy je formální verifikace. Jenže ta má náklady ještě vyšší než testy. Proto jsem se tu snažil dopracovat k výhodnějším technikám, které by třeba byly na půl cesty, nebo z úplně jiné strany (například psaní axiomatických systémů, které vygenerují požadovaný systém rozvojem z několika konfiguračních voleb).

[Martin Tůma]

Na to jsi reagoval tím, že ty testy mám napsat a že je pokrytectví psát testy, co testují jen vlastní vrstvu abstrakce.

Reagoval jsem na to dotazem, jestli jste ty testy napsali, když by podle tebe problémy 7Zipu vyřešili. Na což se mi dostalo (očekávané) odpovědi, že nikoliv, že to nikdo nezaplatí. A to je přesně to jsem chtěl ukázat - někdo do těch testů musí investovat, samy se nenapíšou. Autoři se zkrátka svůj čas/peníze rozhodli investovat do něčeho jiného, stejně tak jako vy, když jste místo testů radši nasadili mnohem levnější sandbox.

[xxx]

Nikdo netvrdi, ze testy jsou k nicemu. Jen nekteri tvrdi, ze se dneska pisi testy bez ohledu na naklady a prinosy.

Napises pitomou parsovaci funkci, pak napises asi tak milon testu na vsechny mozny vstupy te funkce. Nacez celou tu slavu pohrbis pod dalsich milion vrstev, ktere ti zredukuji mnozstvi vstupu na minimum. Ma smysl v takovem pripade psat ony testy, a za jakou cenu? Aby te vsichni pochvalili za moderni pristup?

Nezapomina se trochu na podstatu problemu, ze programatori produkuji chybny kod, procez testy maji chyby odhalit? Ale stejni programatori pisi i chybne testy. Jak casta je pak kombinace chybny kod/chybny test? Ocividne dost casta na to aby nekdo vymyslel mutacni testy. Neni ale nejak jina lepsi cesta?

Skoro mi prijde, ze je to jak kdybyc vzal Valgrind, zjistil jsem, ze mam kod s memleaky a misto toho abych se poucil a snazil se strukturovat svuj kod, tak abych minimalizoval riziko teto chyby, tak misto toho jen zacnu zbesile poustet Valgrind jeste vic.

[Bystroushaak]

Napises pitomou parsovaci funkci, pak napises asi tak milon testu na vsechny mozny vstupy te funkce. Nacez celou tu slavu pohrbis pod dalsich milion vrstev, ktere ti zredukuji mnozstvi vstupu na minimum. Ma smysl v takovem pripade psat ony testy, a za jakou cenu? Aby te vsichni pochvalili za moderni pristup?

Smysl to má, aby sis byl jistý její korektností. Nejen teď, ale i za rok, až na kód sáhnou tři další lidé, kteří pracují pod časovým presem a nemusí mít ani k dispozici původní zadání. Je jen na tobě, kdy si budeš dostatečně jistý, myslím že nikdo netvrdí, že musíš psát tech testů "milion".

Nezapomina se trochu na podstatu problemu, ze programatori produkuji chybny kod, procez testy maji chyby odhalit? Ale stejni programatori pisi i chybne testy.

To ani zdaleka není pravidlo. Zažil jsem firmy, kde testy psali (a dělali) jiní lidé, než lidé co programovali kód. Jejich prací doslova bylo najít chyby v programu.

Jak casta je pak kombinace chybny kod/chybny test? Ocividne dost casta na to aby nekdo vymyslel mutacni testy. Neni ale nejak jina lepsi cesta?

Já si o ní rád poslechnu, zatím jí tu ale nikdo neprezentoval. Pokud tedy "lepší" myslíš jako "méně chybný", ne jako "píše se mi rychleji".

[Martin Tůma]

Ten Valgrind není zrovna moc dobrý příklad, protože tam ty náklady na to, ten test provést (alespoň před releasem a alespoň běžných cest) jsou v porovnání s přínosy dost malé. Věřím, že existují i projekty, kdy nemáš ani hodinu času navíc to v tom Valgrindu pustit, ale zas tak moc jich nebude...

[podlesh]

Nikdo netvrdi, ze testy jsou k nicemu. Jen nekteri tvrdi, ze se dneska pisi testy bez ohledu na naklady a prinosy.

To není pravda: tito "někteří" (warning: wasel words) také tvrdí, že náklady jsou extrémně vysoké a přínosy minimální, ba zanedbatelné. To je výrazně silnější tvrzení a velmi špatně se s ním polemizuje. Musel bych nějak vyjádřit že testy píšu právě s ohledem na náklady a přínosy, a že mé praktické zkušenosti ukazují na naprosto opačný poměr nákladů a přínosů.

Napises pitomou parsovaci funkci, pak napises asi tak milon testu na vsechny mozny vstupy te funkce. Nacez celou tu slavu pohrbis pod dalsich milion vrstev, ktere ti zredukuji mnozstvi vstupu na minimum. Ma smysl v takovem pripade psat ony testy, a za jakou cenu? Aby te vsichni pochvalili za moderni pristup?

Má to cenu pokud ta funkce bude použita i někdy v budoucnu, v novém kódu. Nebo ta vrstva nad ní, která možná vstupní rozsah omezí, ale ne úplně. Nebo další vrstva... atd... Pokud má opravdu funkce fungovat jen pro velmi omezený rozsah vstupních parametrů, tak to v první řadě omezím assertů na vstupu, které automaticky a jasně dají najevo, že se jedná o špatné volání. Nebo, pokud je to v daném jazyce možné, tak ty parametry omezím pomocí typů.

No, a už tady zase trávím čas vysvětlováním základních věcí někomu kdo o to naprosto nestojí a jediné čeho se dočkám jsou urážky.

Seru vám na to, vy mě taky!

[Bystroushaak]

Seru vám na to, vy mě taky!

Nasrat i tobě :)

[xxx]

Jestli on neni ten trik v tom vyvarovat se psani mrtveho kodu, ktery neni nikde pouzity (krome toho ze pro nej napises unit testy) a to co je pouzite testovat na vyssi urovni. Ale chapu, ze to neni mozny vzdycky, treba pri psani knihoven se tomu nevyhnes uz jen proto, ze vyssi vrstvy nemusi jeste existovat. Usetris dvakrat, protoze nepises zbytecnosti, ktery se mozna nekdy pouziji a nepises na ne testy. Ale v mozna jsem v tomhle pristupu poznamenanej tim, ze jsem sem videl, jak to dopada, kdyz se pisou vzdusne zamky, jejichz nejpodstatnejsim prinosem bylo, ze se to udelalo znovu a lepe.

[deda.jabko]

Pozoruji, ze znacna cast populace (nebo diskutujicich zde na abcl) je ochotna prehodnotit sva stanoviska teprve tehdy, az nekdo predstavi 'lepsi' postupy, metodiky, reseni. Do te doby jsou ochotni pouze priznat, ze jimi preferovany postup neni 'samozrejme to absolutni reseni', ale dokud nekdo neprinese neco prukazne lepsiho, tak se u toho stavajiciho zustane.

A jak by se tedy meli (podle tebe) zachovat?

[johnyK]

no ja si predstavuji ze nekdo takovy by napsal treba nasledujici reakci:

Panove, ja tedy bezne pouzivam unit-testy a dodnes jsem byl presvedcen, ze je to vic jak smysluplne, ale nektere prispevky v diskuzi me prinutily k zamysleni. Kratce ty, ktere me zaujaly:

nejaky pan Tuma krome toho, ze tady broji proti tem unit-testum take upozornil na zajimavou skutecnost, ze prevazna cast software, ktere dnes a denne pouzivame temi unit-testy neprosla a presto vpodstate dobre funguje. Priznam se, ze tohle me jeste nenapadlo.

JS1 nadhodil to s temi asserty, to je vlastne taky zajimava myslenka a hlavne ta poznamka o volbe vhodnych nastroju a metod (typovani, funkcionalni jazyky) jako prostredek k omezeni chyb - hm, asi se zamyslim. Mimojine, to s temi funkcionalnimi jazyky navrhoval jiz v 80. letech Backus (Fortran) v te sve legendarni prednasce.

nejaky JohnyK by no sel uplne jinak a navrhuje se poucit u jinych prumyslovych odvetvi a ze je potreba skoncit s temi projekty. U toho jsem jeste skepticky, protoze to srovnavani odvetvi je osemetna zalezitost - tomu bych zatim moc neveril

i to Linusovo ... compiler bez chyby=OK, bootuje=excelentni je vlastne take memorandum proti testum

Takze kdyz to podskrtnu, tak pro me z te diskuze vychazi, ze i nadale budu ty unit-testy delat ale v kazdem pripade si sezenu dalsi informace, jestli je to skutecne nutne. Nakonec jsem tuhle mluvil s klukama u piva o tom testovani a jeden tvrdil, ze naklady na testovani jsou u tech projektu okolo 50% celkovych nakladu. To odpovida tomu co vlastne rika ten Tuma, ze je to nakladne. A mozna to fakt lezi na tech projektech.

[deda.jabko]

nejaky pan Tuma krome toho, ze tady broji proti tem unit-testum take upozornil na zajimavou skutecnost, ze prevazna cast software, ktere dnes a denne pouzivame temi unit-testy neprosla a presto vpodstate dobre funguje. Priznam se, ze tohle me jeste nenapadlo.

V podstate dobre funguje je eufemicky preklad, pro "lidi uz si na chyby v software zvykli natolik, ze nejaky pad nebo divne chovani systemu jim tolik nevadi, kdyz to neni zase moc casto".

JS1 nadhodil to s temi asserty

Asserty znam jeste z minuleho stoleni a paradoxne to byl asi jeden z mala relevantnich prispevku do diskuze, ale ze by to byl argument proti unit testum se rict neda.

nejaky JohnyK by no sel uplne jinak a navrhuje se poucit u jinych prumyslovych odvetvi a ze je potreba skoncit s temi projekty.

Zajimave je, ze jina prumyslova odvetvi s testovanim problem nemaji, casto mnohem nakladnejsim, protoze se likviduji jednotlive fyzicke vyrobky, provadi se draha mereni, a nikdo proti tomu nic nenamita.

a jeden tvrdil, ze naklady na testovani jsou u tech projektu okolo 50% celkovych nakladu. To odpovida tomu co vlastne rika ten Tuma,

A kdyz jsme u toho prehodnocovani, proc porad ti odpurci testu vidi jen tu nakladovou stranku a nevidi tu podstatnou, tj. navratnost, spocivaji ve snizeni (casovych) nakladu na opravu chyb a v usetrenych clovekomesicich na testovani novych verzi, atd.?

[Bystroushaak]

Asserty znam jeste z minuleho stoleni a paradoxne to byl asi jeden z mala relevantnich prispevku do diskuze, ale ze by to byl argument proti unit testum se rict neda.

Už jen z důvodu, že to (spolu s logy) odhaluje chyby v době, kdy je aplikace u zákazníka / v provozu. Typicky chceš chyby odstranit než se tam dostane.

[Josef Kufner]

V provozu už by asserty neměly vůbec přijít ke slovu. V mnoha starých knihách je dokonce psáno, že do produkčních buildů se vypínají, aby nezdržovaly.

Asserty jsou primárně pro vývoj, aby usnadnily ladění a lokalizaci chyb tím, že sestřelí aplikaci dřív, než chyba uteče někam jinam. Tím pádem je chyba nalezena rychle a chybová hláška dává smysl. A hlavně je ta chyba vůbec nalezena.

[JS1]

Mas vicemene pravdu, jen bych doplnil.

Driv se asserty nechavaly v provozu bezne, bylo to take zname pod nazvem defenzivni programovani (paradoxne, kvuli snaze usetrit se od toho ustoupilo, a dnes se to vraci v jine podobe unit testu - to jsou holt ty modni trendy).

Take byl mnohem castejsi pristup radeji rychle a hlasite selhat, nez se snazit nejak zakryt a opravit chybny vstup. Zase, s nastupem software ktery mohou pouzivat i laici (a narustem ceny lidske prace relativne vuci cene vypocetniho vykonu), je ten druhy pristup vhodnejsi, protoze nevyzaduje drahe experty. (Extremni priklad je browser, ktery se snazi z jakkoli absurdne spatne zformovane HTML stranky vysekat aspon nejakou informaci pro uzivatele.) Ale nevyhodou je, ze se pak nemusi prijit na tolik chyb. (Dalsi vec je, ze selhavani hlasite vyzaduje kvalitni supervizor procesu ve stylu treba Erlangovskeho OTP. Castecne je IMHO na vine Posixovy pristup k signalum.)

Samozrejme, Bystroushaak zapomina, presne jak rikas, ze mohou byt ruzne buildy, a software se pousti i behem vyvoje (v tradicnich metodach se hodne pouzivalo end-to-end testovani misto unit testovani, a tam pak asserty dava smysl mit zapnute).

Bohuzel, s tim jak doslo ke zmene te mody, tak dnes maji IDE skvele nastroje na unit testy, ale end-to-end testy a asserty tak dobry tooling nemaji. Napriklad minimalne bych si predstavoval, ze by bylo mozne si vybrat, jaky assert se vypne pro produkci a jaky ne (a osobne bych pro produkci vypinal jen ty prilis narocne na vykon). (Zajimave je, ze treba JVM vlastne ma jiste asserty implicitne v sobe, treba kontrola mezi poli nebo nulovych pointeru. Driv toto byly volby kompilatoru.)

Dalsi vec, ktera je uzitecna a take se zatim moc neprosadila je urcita unifikace konceptu testu a assertu treba jak to dela QuickCheck.

[Bystroushaak]

Samozrejme, Bystroushaak zapomina, presne jak rikas, ze mohou byt ruzne buildy, a software se pousti i behem vyvoje (v tradicnich metodach se hodne pouzivalo end-to-end testovani misto unit testovani, a tam pak asserty dava smysl mit zapnute).

Já jsem v tomhle asi ovlivněn dynamickými jazyky.

Bohuzel, s tim jak doslo ke zmene te mody, tak dnes maji IDE skvele nastroje na unit testy, ale end-to-end testy a asserty tak dobry tooling nemaji. Napriklad minimalne bych si predstavoval, ze by bylo mozne si vybrat, jaky assert se vypne pro produkci a jaky ne (a osobne bych pro produkci vypinal jen ty prilis narocne na vykon). (Zajimave je, ze treba JVM vlastne ma jiste asserty implicitne v sobe, treba kontrola mezi poli nebo nulovych pointeru. Driv toto byly volby kompilatoru.)

D tohle má řešené docela zajímavě pomocí různých version scopes.

[johnyK]

Zajimave je, ze jina prumyslova odvetvi s testovanim problem nemaji, casto mnohem nakladnejsim

samozrejme, ze se v jinych odvetvich testuje. Ale dela se to podle me trochu jinak. Analogie unit-testu ve stavebnictvi by bylo, ze kdyz se v baraku vymneni okna, tak se take zkontroluje jestli jeste porad funguje horak v teplovodnim kotli, jestli jeste funguje zvonek, zamek do hlavnich dveri, jestli nezacala nekde kapat voda z kohoutku, netece vana, jeste porad splachuje zachod ......

Jak uz jsem vyse uvedl, rad bych o tom neco napsal. Neni to samozrejme z me hlavy, ale nez se k tomu dostanu, tak pro zainteresovane jeden ze zajimavych zdroju z teto oblasti. Nancy Leveson (profesorka na MIT) uverejnila uz 1994 clanek o tom, jak by se mel softwarovy prumysl inspirovat u strojirenstvi.

http://sunnyday.mit.edu/steam.pdf

[deda.jabko]

Analogie unit-testu ve stavebnictvi by bylo, ze kdyz se v baraku vymneni okna, tak se take zkontroluje jestli jeste porad funguje horak

To je pitomost par excellence. Pokud chces, muzes si spustit konkretni test pro danou jednotku (metodu, tridu), nikdo te nenuti testovat vsechno, kvuli jedne drobne zmene, i proto se to jmenuje jednotkove testy, testuje se nejmensi jednotka. Pripadne muzes si vytvorit sady testu pro konkretni oblast, pokud mas nejak uzce provazane komponenty. Pripadne, pokud chces, muzes otestovat vse.

A vis, proc muzes otestovat vse? Protoze to skoro nic nestoji. Par sekund procesoroveho casu. Co by za to jina odvetvi dala! Cas, ktery bys jednou venoval otestovani tak jako tak, se nekolika nasobne zuroci s kazdym releasem, kdy se overi vsechen kod. Ale chapu, ze pro spoustu lidi je pohodlnejsi nechat uzivatele hlasit chyby (v horsim pripade trpet), nez aby si overili, ze jejich prace je v poradku.

[Bystroushaak]

samozrejme, ze se v jinych odvetvich testuje. Ale dela se to podle me trochu jinak. Analogie unit-testu ve stavebnictvi by bylo, ze kdyz se v baraku vymneni okna, tak se take zkontroluje jestli jeste porad funguje horak v teplovodnim kotli, jestli jeste funguje zvonek, zamek do hlavnich dveri, jestli nezacala nekde kapat voda z kohoutku, netece vana, jeste porad splachuje zachod ......

Pokud se chceš bavit konkrétně o unittestech, tak analogie by byla, že výrobce cihly otestuje její zatížení a strukturální pevnost a vyrobí si na to malé testovací zařízení, kterým testuje každý stý vyrobený kus. Toto zařízení, respektive parametry, které otestuje pak používá jako jistou garanci zákazníkovi.

To samé výrobce dveří, ten má třeba zase rám a zkouší nějakým strojem jak dlouho vydrží panty a jestli se vůbec dají otevřít a jak silně s nimi jde prásknout, než vypadnou z rámu. Výrobce tašek na střechu zkouší nějakým testovacím zařízením jak dlouho přežijí, erozi pod kyselými látkami, pevnost a pružnost atd.. To je analogie unit testů ve stavebnictví, neboť testují konkrétní malou a dál špatně dělitelnou jednotku.

To co jsi popsal ty je spíš obecné testování, které dělá tester interaktivně po nějaké změně. A většina jich netestuje všechno, ale jen část které se změna týkala, například po výměně dlažby v koupelně otestuje jestli neteče voda o patro níž, jestli vůbec teče voda, jestli odtékají odpady, svítí světla a tak. Možná se to zdá jako blbost, ale nám třeba zedníci už doma zazdili odpad ve sprše, takže se kvůli tomu musela vybourávat. To ovšem není unittest.

[Martin Tůma]

http://sunnyday.mit.edu/steam.pdf

Nevidím tam nic zas tak převratnýho, nicméně zdejší uctívači kultu unit testů by si to přečíst mohli. Na několika příkladech z letectví je tam totiž zmiňován celkem důležitý poznatek, že pokud se člověk začne spoléhat na automatické systémy, které hlídají chyby za člověka, začne jít ostražitost a kvalita dolů. A přesně takové chování - "můžu commitovat cokoliv, protože mi unit testy zaručí, že jsem nic nerozbil" - se tady někteří snaží vydávat za výhodu unit testů.

[Bystroushaak]

A přesně takové chování - "můžu commitovat cokoliv, protože mi unit testy zaručí, že jsem nic nerozbil" - se tady někteří snaží vydávat za výhodu unit testů.

Tohle tvrzení vidíš jen díky předsudkům vůči nim.

[Martin Tůma]

Řekl bych, že ho vidím především proto, že - na rozdíl od tebe (jak už jsem jednou upozorňoval) - skutečně čtu, co sem lidi píšou... Následující dva příklady jsou přesné citace:

neni nad to, kdyz vyvojar muze posilat co chce a testy mu hned reknou = takto ne

tak ten cas radeji venuju napsani testu, ktere muzu pouzit kdykoliv a za par sekund (nebo setin sekund) si muzu overit, ze vsechno funguje, jak ma, a nic jsem nerozbil

[deda.jabko]

Pred casem jsem videl ve zpravach reportaz, ze bude letos malo slamy. Ale tento problem se te evidentne netyka, protoze tva zasoba slamennych panaku vypada jako nevycerpatelna.

tak ten cas radeji venuju napsani testu, ktere muzu pouzit kdykoliv a za par sekund (nebo setin sekund) si muzu overit, ze vsechno funguje, jak ma, a nic jsem nerozbil

vs.

"můžu commitovat cokoliv, protože mi unit testy zaručí, že jsem nic nerozbil"

Je ponekud rozdil.

[Martin Tůma]

Věřím, že dokážeš najít obrovský rozdíl i v tom druhém případě. A ten pokus na jeden domnělý argumentační faul upozornit jiným argumentačním faulem mi přijde absurdní, ale budiž.

[deda.jabko]

Na několika příkladech z letectví je tam totiž zmiňován celkem důležitý poznatek, že pokud se člověk začne spoléhat na automatické systémy, které hlídají chyby za člověka, začne jít ostražitost a kvalita dolů.

V rade prumyslovych odvetvi je maximalni snaha omezit lidsky faktor, protoze selhava az prilis casto a stoji za zvysenymi naklady. Je to tak zasadni tema, ze tomu dokonce venuji cele vedni obory. A tvuj navrh, ktery tady neustale opakujes, je, ze s chybami zpusobenymi lidskym faktorem se vyparadame tak, ze odstranime bezpecnostni/kontrolni mechanismy.

[Martin Tůma]

Tak jestli já mám zásobu slaměných panáků, tak ty potom vlastníš celou terakotovou armádu...

[Bystroushaak]

Nakonec jsem tuhle mluvil s klukama u piva o tom testovani a jeden tvrdil, ze naklady na testovani jsou u tech projektu okolo 50% celkovych nakladu. To odpovida tomu co vlastne rika ten Tuma, ze je to nakladne. A mozna to fakt lezi na tech projektech.

Pozor, testování v tomhle kontextu asi nebudou unittesty. Například u nás máme dedikované testery, kteří po každé issue aplikaci zkouší ze všech možných hledisek. Samotné psaní unittestů mi většinou zabere odhadem tak .. 20% času, který navíc nevyžaduje moc mentionů (jednotek přemýšlení). Oproti tomu vývoj samotný v závislosti na komponentě může žrát mentionů fakt hodně :)

[podlesh]

co pořád dokola hejtuje cargo cult testů

ja nejsem v zadnem pripade advokat pana Tumy i kdyz s nim vpodstate souhlasim. Feynman, kdyz kritizoval ten cargo-cult, tak nabadal, aby vedci, inzenyri, lekari byli proste kazdy den ochotni a pripraveni prehodnotit sve zazite nazory, postupy. To u vas nepozoruji (a u znacne casti zde obdobne diskutujicich) a proto se nedivim, ze pan Tuma jeste neni z vasich odpovedi zcela uspokojen.

Ok, zásadní otázka: jak jste (s panem Tůmou) přehodnotili své zažité názory? Přeci nejste členy cargo cultu, že ne?

Pozoruji, ze znacna cast populace (nebo diskutujicich zde na abcl) je ochotna prehodnotit sva stanoviska teprve tehdy, az nekdo predstavi 'lepsi' postupy, metodiky, reseni. Do te doby jsou ochotni pouze priznat, ze jimi preferovany postup neni 'samozrejme to absolutni reseni', ale dokud nekdo neprinese neco prukazne lepsiho, tak se u toho stavajiciho zustane.

Ať se na to dívám jak se na to dívám, tak mi to přijde jako naprosto racionální chování. Tedy dokud platí, že původní postup má pozitivní přínos.

Tento muj prispevek nemel ted vyresit tu problematiku tech unit-testu, jen jsem chtel z meho pohledu upozornit na to, proc se ta diskuze toci dokola a tocit bude, protoze ani pan Tuma, a ani napr. ja nedokazeme zde na nekolika radcich predlozit to 'lepsi' reseni.

Já mám alternativní hypotézu: diskuse se točí pořád dokola, protože je v principu politická (a to velmi současně politická). Ale jelikož o politický flamewar nestojím, tak to raději nebudu rozvíjet. Navíc raději nechci nikoho urážet (předpokládám že vy asi z vaší strany nic urážlivého nevidíte a brali byste to jako nevyprovokovaný útok z mojí strany).

[Martin Tůma]

Víš, ono by možná nebylo na škodu číst, co sem lidi píšou... Já nezavrhuju unit testy jako nástroj pro vývoj SW, jenom poukazuju na to, že tento nástroj zdaleka není vhodný/výhodný pro každý projekt. Toto pak dokazuji na reálném světě, kde perfektně fungující projekty se složitostí a důležitostí, jakou pravděpodobně tvůj (ani můj) projekt nikdy mít nebude - například linuxový kernel - žádné unit testy nemají.

Že jsem v tomto názoru konzistentní napříč diskuzí ti možná připadá jako "kolovrátek", ale rozhodně je to mnohem serióznější, než to, co tady předvádíš ty. A tím myslím třeba to vypuštění "nepodstatného" slovíčka "unit" nebo když se "průser jak vrata" (za cizí peníze) najednou změní v "relativně malou komponentu" (a testy za vlastní peníze najednou nejsou potřeba).

[Bystroushaak]

Víš, ono by možná nebylo na škodu číst, co sem lidi píšou... Já nezavrhuju unit testy jako nástroj pro vývoj SW, jenom poukazuju na to, že tento nástroj zdaleka není vhodný/výhodný pro každý projekt. Toto pak dokazuji na reálném světě, kde perfektně fungující projekty se složitostí a důležitostí, jakou pravděpodobně tvůj (ani můj) projekt nikdy mít nebude - například linuxový kernel - žádné unit testy nemají.

Ok, tuhle pointu uznávám. Na druhou stranu tohle imho není to jediné, co jsi prezentoval zde v diskuzi.

A tím myslím třeba to vypuštění "nepodstatného" slovíčka "unit"

To slovíčko "unit" skutečně do jisté míry považuji za nepodstatné a mezi unittesty a testy třeba API nevidím velký rozdíl a zcela běžně je míchám dohromady. Uznávám to jako svojí chybu.

nebo když se "průser jak vrata" (za cizí peníze) najednou změní v "relativně malou komponentu" (a testy za vlastní peníze najednou nejsou potřeba)

Fakt nechápu, co se mi tady snažíš podstrčit. Průser jak vrata je mít komponentu, která libovolnému uživateli umožní spustit cizí kód a nevědět o tom. Relativně malá komponenta to byla, testovaná byla (integračně a na úrovni API) a chyba v 7zipu byla vyřešena sandboxem, spolu s další neschopností autorů 7zipu psát bezpečný software, který vede s železnou pravidelností na kritické zranitelnosti.

[Martin Tůma]

Navíc bych ještě poznamenal, že ten kód je jeden z těch, kterým se bezpečnostní experti zabývají velice často (je například součástí packerů Avastu/AVG a byl i pod drobnohledem Googlího Project Zero), takže daný počet CVE bych v tomto ohledu viděl jako velice dobrou vizitku.

[Michal Kubeček]

On nám také termín "CVE" v posledních letech hodně zdevalvoval. Za poslední dva týdny mi rukama prošo 4-5 "CVE" na tcpreplay. Všechny do jednoho vypadaly tak, že někdo vzal záměrně poškozený pcap file, pustil to s nějakými parametry pod valgrindem a jakmile to vyhodilo čtení nebo zápis kousek vedle bufferu, honem si běžel zaregistrovat CVE. A pak to teprve nahlásil projektu. Nějakou analýzou, jak moc (a jestli vůbec) je to opravdu bezpečnostní problém, se pochopitelně nezatěžoval, některé popisy neodpovídaly skutečnosti, jednou dokonce tvrdil, že problém je ve větvi, kde už byl měsíce opravený, …

Cílem takového počínání očividně není řešit bezpečnost, ale nahnat co nejvíc CVE do CV. Bohužel ale asi existují firmy, které hodnotí "bezpečnostní experty" podle počtu ulovených CVE, jinak by to tihle lidé nedělali.

[johnyK]

ja bych si dovolil tvrdit, ze Vas prispevek je klasicka ukazka toho, proc nekteri vyvojari na ty unit testy neveri.

Mel jsem v praci kolegu co tvrdil, ze dokaze psat bez chyb, fajn dal mi svou fci, ja mu ji rozbil.

treba byl ten vas kolega mizerny programator a jeste k tomu vejtaha

Vse je o spravne kombinaci vsech techto vrstev

nemohl byste sem dat odkaz, jak vypada ta spravna kombinace v nejakem konkretnim pripade. Podle ceho se to ridi, Na cem to obecne zavisi?

je to o spravnym mixu a ten je proste o zkusenostech

kde se daji sehnat ty zkusenosti? Kolik stoji 1 kg zkusenosti? Podle ceho pozna vedouci projektu, kolik je v tymu zkusenosti. Jak se to meri?

chybam je treba kontrolovane predchazet.

ano, na tom se shodneme. Pred 30 lety nikdo unit testy nepsal a software fungovalo zrovna tak dobre nebo spatne jako dnes. Predchazet chybam se da ruzne, kolega JS1 to nahore popsal.

[Dirka]

treba byl ten vas kolega mizerny programator a jeste k tomu vejtaha

Muj nazor je ze oboje, ale to nic nemeni na situaci, ze neexistuje clovek, co nedela chyby.

nemohl byste sem dat odkaz, jak vypada ta spravna kombinace v nejakem konkretnim pripade. Podle ceho se to ridi, Na cem to obecne zavisi?

A co cekas? Podle me je jedina spravna cesta poucit se z chyb i.e. regrese. Up-front nikdy nemas sanci.

ano, na tom se shodneme. Pred 30 lety nikdo unit testy nepsal a software fungovalo zrovna tak dobre nebo spatne jako dnes. Predchazet chybam se da ruzne, kolega JS1 to nahore popsal.

Bez urazky, ale odsazeni v T602 neni to stejny jako handling corrupted "binary_sracky" aka input data nebo interkomunikace mezi 15 sluzbama, asi si nerozumime.

[JS1]

Bez urazky, ale nevis nic o historii enterprise softwaru.

Jeden z prvnich aplikacnich serveru - CICS - mel jadro formalne zverifikovane. Ktery AS to dnes ma? Ktery pouzivany otevreny distribuovany system to ma?

Mam silnou pochybnost, ze vase aplikace potrebuje 15 sluzeb. Nicmene, i kdyby, unit testy ti moc nepomuzou, protoze to co potrebujes primarne testovat v takovem pripade jsou predpoklady, ktere splnuji data, ktera jdou do tech sluzeb. Prvni vec k ladeni takoveho systemu je, ze potrebujes vedet, jestli ti nekdo poslal spatna data, nebo jestli ty vyrabis spatna data. Asserty (nad daty) jsou pro takovy system mnohem dulezitejsi nez unit testy. A pokud ty asserty mas, muzes nasadit neco jako QuickCheck.

Paradoxni na tom je, ze zpusob, jakym se veci psaly driv, byl opravdu hrozny. Dneska bychom to mohli delat mnohem lepe.. ale ne kargo kultem unit testu. Ono vlastne ani o takovou novinku nejde.

Videl jsem treba implementaci Lispu z 80. let pro mainframe - a samozrejme, ze ma automatizovane unit testy na kazdou funkci ze zakladni knihovny. To je pripad (jak psal uz Bystroushaak), kde to totalne dava smysl.

Ale je otazka, do jake miry jsou to jeste unit testy. Unit testy testuji vnitrek aplikace, nikoli povrch vystaveny uzivateli, jako to delaji spis integracni testy. A aplikace se lisi pomerem povrch/objem - u programovaciho jazyka jsou treba funkce zakladni knihovny tim povrchem, tzn. povrch je velky v porovnani s objemem. Naproti tomu treba resic pro nejakou matematickou ulohu muze byt vnitrne dost slozity, ale vstupni bod (povrch) je pomerne jednoduchy (zadani).

[Dirka]

Sorac, ale to o T602 snad bylo pochopitelny jako nadsazka? Takze nebylo, beru jako poznamku pro sebe.

A ano, nase aplikace opravdu vyuziva 15 service, nicmene to neni jedinej konzument tech sluzeb; mimoto pisi v tom prvnim prispevku o vhodne kombinaci ruznych typu testu, takze opravdu neverim na mantru pouze u-testu.

[JS1]

Nebylo, pro mnoho lidi totiz vyvoj SW (a best practices s tim spojenych) zacal na mikropocitacich v 80. letech, coz je pochopitelne, ale dost ahistoricke.

Je to trochu jako s objevenim Ameriky.. taky slo o objeveni Ameriky.

[podlesh]

ja bych si dovolil tvrdit, ze Vas prispevek je klasicka ukazka toho, proc nekteri vyvojari na ty unit testy neveri.

Víra není nutná, možná dokonce kontraproduktivní. Něco jako náboženství na Zeměploše

chybam je treba kontrolovane predchazet.

ano, na tom se shodneme. Pred 30 lety nikdo unit testy nepsal a software fungovalo zrovna tak dobre nebo spatne jako dnes. Predchazet chybam se da ruzne, kolega JS1 to nahore popsal.

Fakt? Podle toho co jsem četl tak to před třiceti lety (tj. v osmdesátých letech) fakt nefungovalo dobře a dnes je to (statisticky) mnohem, mnohem lepší. Samozřejmě ne primárně díky unit testům, ale každá troška dobrá.

PS: Tak nějak počítám s tím, že si všichni v této diskusi mluvíme o práci v týmech na SW definovaném z vnějšku (mimo tyto týmy). Člověk pracující sám na něčem co si sám vymyslel je naprosto odlišný případ!

[Michal Kubeček]

Ja osobne zastavam nazor, ze kazdej nove nalezenej bug si zaslouzi formu testu (na spravne urovni), tzn uz nikdy vice regrese!

To je poněkud přehnané. Nechtěl jste spíš říci "nikdy více znovu tahle konkrétní regrese"?

[Dirka]

Jasny, ale pride mi to jako bazirovani na slovickach, byt to mozna nebylo uplne jasny.

[Martin Tůma]

Aha, tady vidim ten zásadní problém, dávaš rovnítko mezi "nelze psát bez chyb" a "nelze psát bez (automatických) testů". Tam ale žádné rovnítko opravdu není. Ano bez chyb se psát nedá, to si tu nikdo předpokládám nemyslí, ale to ještě vůbec neznamená, že nelze psát bez (automatických) testů. To samozřejmě lze a běžně se to taky dělá. Jestli (automatické) testy pro ten který SW dávají smysl (a sem počítám samozřejmě i ekonomický) je prostě specifické pro ten který projekt.

[Dirka]

Abych parafrazoval Mr. Tuma - stahl jsem si jeho "intergalaktický" GPXsee a zkusil jsem zacatecnickej test z prvni tridy QA.

- soubor bez hlavicky
- prazdnej soubor
- soubor bez radnyho ukonceni
- soubor bez casovyho udaje (export z mapy.cz tzn jen koordinaty + elevation)

Vysledek:

- poskozeny soubory detekuje spravne

Nicmene:

Nactu v poradi ok + spatnej + spatnej + spatnej, kliknu na sipku zpet a sipku nasledujici trasa --> "Error loading data"

Well done, urcite tam nebude zadnej memory leak, kdyz ani nezahodime reference na nevalidni soubory.

- export z mapy.cz

Spravne neukazeju sped tab, nicmene zalozka elevation je prazdna (prestoze v tom souboru jsou).

Toto mi zabralo 5 min vcetne kompilace na gentoo bez znalosti app a pouzil jsem pouze ctrl+O a dve tlacitka na toolbaru. Nemam v umyslu nijak shazovat usili na te app, ale od cloveka s tak silnym nazorem v diskuzi bych cekal, ze je vetsi frajer.

PS - verze 5.17, simple zkopirovani ebuildu a prepsani na 6.3 hodilo nakou chybu a  nemam v umyslu tim travit cas, podle changelogu to nevypada na opraveny v 6.3. Jinak peace kemo a trochu pokory.

[xxx]

Vis a vo tom to je. Bud mas cas resit problemy, ktery se tykaji autistickej testeru, nebo resit aby v tom fungovaly spravne normalni veci. Takze ano, nemelo by to tam bejt, ale koho to zajima a okolik by bylo GPXSee lepsi pro normalniho uzivatele?

[Martin Tůma]

Musím říct, že jsem tedy dost zklamán... Chvíli jsem měl radost, že můj čas strávený zdejší diskuzí nebyl zbytečný, neboť to někoho vyprovokovalo k otestování GPXSee (v což jsem tak trochu doufal), ale bohužel, nic z popsaného není žádný bug ale správné chování. Tedy můžeme samozřejmě diskutovat o odstínu té šedé, kterou je v grafu napsáno "Data not available", pokud si chcete zobrazit data v závyslosti na čase a soubor čas neobsahuje. Záložka s výškou v tomto případě mizet nemá, protože data jsou dostupná pro závyslost na vzdálenosti.

Co se týče toho druhého "bugu", tak tady nechápu, co by se jiného než popisované chování mělo dít? Pokuď procházím směrem vpřed soubory v pořadí: ok, špatný, špatný, špatný, tak logicky v okamžiku, kdy na konci směr otočím očekávám, že dostanu sekvenci: špatný, špatný, ok.

Takže znovu a lépe prosím!

[Dirka]

Tak jo.

[Martin Tůma]

Budu se těšit, protože jak už jsem psal - pokuď jsou (jakékoliv) testy za čas/peníze někoho jiného, je nesmysl je nemít.

Jinak co se týče toho ebuildu, tak tady předpokládám, že tam bude scházet závyslost na libQt5Sql, která je od verze 6.x nová. Bylo by hezké, řešit případné bugy v aktuální verzi.

[Michal Kubeček]

Je mi jedno, jestli budu za grammar nazi, tohle je prostě moc. Poprvé jsem myslel, že je to překlep, ale vy jste to napsal v rychlém sledu třikrát, takže to asi myslíte vážně. Takže pro vaši informaci: závislost.

[Martin Tůma]

No pravda je, že zrovna s tímto slovem mám celkem problém. Nejenom, že to není překlep, ale asi tak v každém svém druhém textu sáhnu po Googlu, abych zjistil, jak se to vlastně píše. A stejně to pak příště napíšu zase špatně... Grammar nazi si v zásadě přijde na své u každého mého textu, ale v okamžiku, kdy se účastním flamewar, je to obzvlášť bída.

Chtěl jsem vám napsat, že tudíž děkuji za opravu ale je to naprosto zbytečné, nicméně při kontrole jiného slova jsem teď objevil možnost v Chromiu zapnout kontrolu pravopisu přes Google, takže to úplně zbytečný možná nebylo