Typový system versus unittesty

[Kit]

Funkce se da vyjadrit:

• analyticky - o to se vetsina programatoru snazi
• graficky - o to se vetsina programatoru nesnazi, ale mohlo by to byt zajimave
• vyctem hodnot - o to se vlastne snazi BoneFlute, akorat se mu nechce psat vsechny tak "zneuziva" typovy system

Asi bych se nespokojil s tím, že chápu funkci jen jako výčet hodnot, ale uznávám, že většina mejch ukázek je o tom.

Ale to grafické vyjádření funkce by mě zajímalo. Můžeš to prosím rozvést?

Nemuzu. Nerozumim tomu :-). Vychazel jsem jen z toho, ze v matematice lze funkci vyjadrit tremi zpusoby. Dva z nich jsou pouzitelne i v programovani, tak proc ne ten treti?
Jedine co si dovedu predstavit je nejake vzorkovani, ktere problem redukuje na vycet hodnot, takze vlastne nuda.

Asi ne vždy, ale jde to i graficky. Vygeneruje se více testovacích hodnot a místo porovnání výsledků se vynesou do grafu. Pohledem na graf nebo srovnáním s etalonem můžeme snadno ověřit, zda funkce funguje jak má. Něco podobného jsem používal na vyhodnocení výsledků adaptivní metody Runge-Kutta pro různé velikosti základního kroku.

[Reklama]

[Filip Jirsák]

který příklad? v jakém systému a proč to nejde? vy furt opakujete, že to nejde, ale zatím váš jedinný argument byl, že to nejde

Ten příklad, kterým začalo tohle vlákno diskuse, na které reagujete. Když už si to nepamatujete, máte v prohlížeči po straně takové táhlo, za to když potáhnete, bude se vám posouvat stránka na obrazovce, a tak se dostanete i k předchozím komentářům v tomto vlákně, můžete si je přečíst – jsou stále ještě na jedné obrazovce.

Máme tam příklad a v komentáři jsou popsané nějaké testy. Pokud jsou podle vás ty testy zbytečné, napište, čím byste je nahradil. Můj argument, proč to nahradit nejde (už jsem to vysvětloval, ale zřejmě jste to nepochopil), je dostatečný – vy jste zatím neuvedl jediný protipříklad, jak to tedy udělat, místo toho se pořád jen na něco vymlouváte.

Shrnu to pro vás ještě jednou –  když máte příklad s testy, a tvrdíte, že testy nejsou potřeba a i bez nich je možné získat minimálně stejnou míru jistoty o správné funkčnosti, předveďte to a upravte ten příklad tak, aby v něm žádné testy nebyly. Pak se můžeme bavit o tom, jestli ty vaše úpravy zaručují stejnou jistotu správné funkčnosti. Dokud to neuděláte, jenom tu plácáte.

[JSH]

Nicmene tvuj priklad krasne ukazuje, ze pri pouziti vhodnych typu ztraci smysl vsechny negativni testy.

Což je ovšem dost slabé tvrzení oproti původnímu „nejsou potřeba žádné testy“.

Ja ani tak nerikam, nejsou potreba, ale spis nejdou napsat. Je to uplne odlisny vyrok. Nedaval bych to do souvislosti.

Z toho ale zároveň plyne jedna velká nepříjemnost. Dost blbě se ověřuje, že nějaký obrat opravdu nejde zkompilovat. Spouštět nějakým scriptem kompilaci kousků kódu a testovat jestli to opravdu zdechne je nešikovné.

[v]

příklad jsem tu uváděl, pokud jste ho ignoroval, vaše škoda

[v]

Nicmene tvuj priklad krasne ukazuje, ze pri pouziti vhodnych typu ztraci smysl vsechny negativni testy.

Což je ovšem dost slabé tvrzení oproti původnímu „nejsou potřeba žádné testy“.

Ja ani tak nerikam, nejsou potreba, ale spis nejdou napsat. Je to uplne odlisny vyrok. Nedaval bych to do souvislosti.

Z toho ale zároveň plyne jedna velká nepříjemnost. Dost blbě se ověřuje, že nějaký obrat opravdu nejde zkompilovat. Spouštět nějakým scriptem kompilaci kousků kódu a testovat jestli to opravdu zdechne je nešikovné.

tohle je zajímavý problém, existuje taková knihovna pro ghc, která se to pokouší řešit https://hackage.haskell.org/package/should-not-typecheck

[Reklama]

[Filip Jirsák]

příklad jsem tu uváděl, pokud jste ho ignoroval, vaše škoda

Tak dlouho tu trollujete, až jste vytrollil sám sebe.

[SB]

Testy obvykle dělám na parsing, a pak asi nějaký test, že to nepočítá úplnou haluz (i.e. 100% code coverage, tady že jsem se neuklep v těch operátorech). Ono tam teda moc co testovat není....  jinak parser na "normální" výrazy není o moc delší, jen jsem línej to hledat... tam by se asi pak řešilo v testech, jestli se korektně respektuje priorita operátorů.

No, ale v podstatě je to to, co jsem psal - parsing typově moc obsáhnout nejde, vlastní výpočet má v podstatě 3 řádky a  není moc co tam splést.... aritmetika na Double je poměrně "totální", takže tam taky není moc co řešit...

Jaktože tam není co testovat? Zde jsou testy efektivní - pro různé kombinace řetězcových výrazů (včetně chybných, s různými mezerami, závorkami atd.) můžu pokrýt mnoho jevů a otestovat, zda z kalkulačky padá, co má.

[SB]

Mohl bych videt prosim nejaky unit test na "funkci" rand?

Psát to sem nebudu, popis musí stačit: Lze testovat např. typ hodnot, interval, rozložení, shodu posloupností v případě implementace se seedem, ...

[andy]

Testy obvykle dělám na parsing, a pak asi nějaký test, že to nepočítá úplnou haluz (i.e. 100% code coverage, tady že jsem se neuklep v těch operátorech). Ono tam teda moc co testovat není....  jinak parser na "normální" výrazy není o moc delší, jen jsem línej to hledat... tam by se asi pak řešilo v testech, jestli se korektně respektuje priorita operátorů.

No, ale v podstatě je to to, co jsem psal - parsing typově moc obsáhnout nejde, vlastní výpočet má v podstatě 3 řádky a  není moc co tam splést.... aritmetika na Double je poměrně "totální", takže tam taky není moc co řešit...

Jaktože tam není co testovat? Zde jsou testy efektivní - pro různé kombinace řetězcových výrazů (včetně chybných, s různými mezerami, závorkami atd.) můžu pokrýt mnoho jevů a otestovat, zda z kalkulačky padá, co má.

Do není pochopitelné na "testy dělám na parsing"?

A co chcete testovat na:

Kód: [Vybrat]

compute :: Expr -> Double
compute = cata go
  where
    go (Num n)       = n
    go (Op op a1 a2) = op a1 a2
Pokud bychom do jazyka přidali prioritu a závorky, tak to je všechno věc parsingu, na tohle to nebude mít žádný vliv.

[Kit]

A co chcete testovat na:

Kód: [Vybrat]

compute :: Expr -> Double
compute = cata go
  where
    go (Num n)       = n
    go (Op op a1 a2) = op a1 a2
Pokud bychom do jazyka přidali prioritu a závorky, tak to je všechno věc parsingu, na tohle to nebude mít žádný vliv.

Testovat můžeš například to, jestli jsi omylem nezaměnil operátory, jestli jsi dal závorky tam, kam patří, jestli omylem nevoláš nevhodnou funkci z knihovny, jestli jsi nezaměnil proměnné nebo pořadí parametrů stejného typu,... Jistě, u jednoduchého příkladu se bez testů obejdeš, podobně jako v OOP, ale neprogramujeme jen jednoduché kalkulačky.

[andy]

A co chcete testovat na:

Kód: [Vybrat]

compute :: Expr -> Double
compute = cata go
  where
    go (Num n)       = n
    go (Op op a1 a2) = op a1 a2
Pokud bychom do jazyka přidali prioritu a závorky, tak to je všechno věc parsingu, na tohle to nebude mít žádný vliv.

Testovat můžeš například to, jestli jsi omylem nezaměnil operátory, jestli jsi dal závorky tam, kam patří, jestli omylem nevoláš nevhodnou funkci z knihovny, jestli jsi nezaměnil proměnné nebo pořadí parametrů stejného typu,... Jistě, u jednoduchého příkladu se bez testů obejdeš, podobně jako v OOP, ale neprogramujeme jen jednoduché kalkulačky.

Reagoval jsem na:

Jaktože tam není co testovat? Zde jsou testy efektivní - pro různé kombinace řetězcových výrazů (včetně chybných, s různými mezerami, závorkami atd.) můžu pokrýt mnoho jevů a otestovat, zda z kalkulačky padá, co má.

Takže rozumíme si, že na výše uvedeném kódu toho fakt k testování moc není?

[listoper]

Mohl bych videt prosim nejaky unit test na "funkci" rand?

Psát to sem nebudu, popis musí stačit: Lze testovat např. typ hodnot, interval, rozložení, shodu posloupností v případě implementace se seedem, ...

Nemel by prave typ hodnot podchytit typovy system? To same interval. Shodu s posloupnosti si taky dovedu predstavit.

[Kit]

A co chcete testovat na:

Kód: [Vybrat]

compute :: Expr -> Double
compute = cata go
  where
    go (Num n)       = n
    go (Op op a1 a2) = op a1 a2
Pokud bychom do jazyka přidali prioritu a závorky, tak to je všechno věc parsingu, na tohle to nebude mít žádný vliv.

Testovat můžeš například to, jestli jsi omylem nezaměnil operátory, jestli jsi dal závorky tam, kam patří, jestli omylem nevoláš nevhodnou funkci z knihovny, jestli jsi nezaměnil proměnné nebo pořadí parametrů stejného typu,... Jistě, u jednoduchého příkladu se bez testů obejdeš, podobně jako v OOP, ale neprogramujeme jen jednoduché kalkulačky.

Reagoval jsem na:

Jaktože tam není co testovat? Zde jsou testy efektivní - pro různé kombinace řetězcových výrazů (včetně chybných, s různými mezerami, závorkami atd.) můžu pokrýt mnoho jevů a otestovat, zda z kalkulačky padá, co má.

Takže rozumíme si, že na výše uvedeném kódu toho fakt k testování moc není?

Psal jsem, co všechno na tomhle můžeš otestovat. Pokud místo posledního řádku omylem napíšeš

Kód: [Vybrat]

    go (Op op a1 a2) = op a2 a1tak to kompilátor sežere i s chlupama a přitom to bude špatně.

[v]

Kód: [Vybrat]

    go (Op op a1 a2) = op a2 a1tak to kompilátor sežere i s chlupama a přitom to bude špatně.

dalo by se to napsat jako

Kód: [Vybrat]

data Expr a where
    Op :: (x -> y -> z) -> Expr x -> Expr y -> Expr z ale nevím jestli to jde s tím rekurzním schématem

[Kit]

Kód: [Vybrat]

    go (Op op a1 a2) = op a2 a1tak to kompilátor sežere i s chlupama a přitom to bude špatně.

dalo by se to napsat jako

Kód: [Vybrat]

data Expr a where
    Op :: (x -> y -> z) -> Expr x -> Expr y -> Expr z ale nevím jestli to jde s tím rekurzním schématem

Pokud jsem dobře pochopil, tak se tohle dělá jen teoreticky. Stejně jako mnozí, kteří dělají testy také jen teoreticky - jenže na ně jsou aspoň metriky, u kterých je nepraktické podvádět.