Typový system versus unittesty

[Gődel]

I tak je ale vhodné použít unit testy pro otestování logiky kódu (to typově dost dobře nejde).

Proč?

Protože třeba funkce vracející k n n-té prvočíslo. Prostě logika se typovým systémem v obecnosti otestovat nedá. Se závislostním typovým systémem jde ale podchytit mnoho věcí již během překladu, což je jeho největší výhoda. Čistě teoreticky kontrolu za běhu nelze zcela vyloučit, protože halting problem. Nicméně některé jazyky zaručují i totalitu funkcí.

[Reklama]

[BoneFlute]

I tak je ale vhodné použít unit testy pro otestování logiky kódu (to typově dost dobře nejde).

Proč?

Protože třeba funkce vracející k n n-té prvočíslo. Prostě logika se typovým systémem v obecnosti otestovat nedá. Se závislostním typovým systémem jde ale podchytit mnoho věcí již během překladu, což je jeho největší výhoda. Čistě teoreticky kontrolu za běhu nelze zcela vyloučit, protože halting problem. Nicméně některé jazyky zaručují i totalitu funkcí.

Rozumím. Prvočísla sou svině.

Ale pokud to chápu dobře, tak zde je problém v tom, že prvočísla se nedají ani otestovat. U typů zase narazím na to, že typ se snaží být ultimátní. Takže bych se přimlouval za plichtu :-) V tomto případě.

[Ondra Satai Nekola]

Kód: [Vybrat]

foo(i):
   if (Random.double(0, 1) > 0.0000001:
      return i + 1
   else
      return "Life suckz!"

print(1 + foo(1))

V testovani na to nejspis neprijdes, typova kontrola to da na prvni dobrou...

Když tam místo "Life suckz!" dáš třeba 0, což bývá častý případ, tak to typová kontrola také nedá.

On taky nikdo nerika, ze typova kontrola da vsechno....

[Kiwi]

Statický typový systém nemá s testováním nic společného. Historicky vznikl kvůli tomu, aby kompilátor mohl generovat rychlý kompaktní kód. Na návrh programu má poněkud komplikační dopad - návrh musí být podřízen statickému typování, ale bez něj by byl jednodušší.

Unit testy píšu kvůli testování funkčnosti, ne kvůli ověřování typů. Pokud budu mít kupř. za úkol napsat nějaký grafový algoritmus, tak unit testem zkouším, zda funguje tak jak má, a ne jestli tam jdou "správné" typy. Statická typová kontrola, jak se zdá, v někom vzbuzuje falešný pocit, že je to nějaký test navíc. Ale to není! Statická typová kontrola mi hází při kompilaci chyby, které tam jsou, jen protože se vyžaduje statická typovost. Je to tak trochu začarovaný kruh. Na jednu stranu mě sice zarazí, pokud omylem použiju nějakou proměnnou na něco jiného (samozřejmě tedy jen pokud to má náhodou i jiný typ), ale na druhou stranu mi zase komplikuje práci, když by ta jedna proměnná klidně mohla obsahovat různorodá data.

Nechci hodnotit, co je lepší nebo horší, obojí má podle mě své místo a opodstatnění. Ale statické typování rozhodně žádné unit testování nenahrazuje.
(osobně mi statické typování překáží tím více, na čím vyšší úrovni abstrakce se pohybuji; na low-level záležitosti mi připadá jako naprosto perfektní)

[Gődel]

I tak je ale vhodné použít unit testy pro otestování logiky kódu (to typově dost dobře nejde).

Proč?

Protože třeba funkce vracející k n n-té prvočíslo. Prostě logika se typovým systémem v obecnosti otestovat nedá. Se závislostním typovým systémem jde ale podchytit mnoho věcí již během překladu, což je jeho největší výhoda. Čistě teoreticky kontrolu za běhu nelze zcela vyloučit, protože halting problem. Nicméně některé jazyky zaručují i totalitu funkcí.

Rozumím. Prvočísla sou svině.

Ale pokud to chápu dobře, tak zde je problém v tom, že prvočísla se nedají ani otestovat. U typů zase narazím na to, že typ se snaží být ultimátní. Takže bych se přimlouval za plichtu :-) V tomto případě.

Obecně platí, že typová kontrola zajistí korektnost vstupu a správný typ výstupu a že všechny funkce na sebe bezchybně navazují. Zároveň zajistí přesměrování chyb za běhu. Nemůže ovšem garantovat správnost výsledků (v některých případech ano, ale obecně ne).

[Reklama]

[Kit]

Ale pokud to chápu dobře, tak zde je problém v tom, že prvočísla se nedají ani otestovat. U typů zase narazím na to, že typ se snaží být ultimátní. Takže bych se přimlouval za plichtu :-) V tomto případě.

Prvočíslo se dá otestovat velmi snadno.

[BoneFlute]

Nemůže ovšem garantovat správnost výsledků (v některých případech ano, ale obecně ne).

Dobře. Ale já se táži proč.

[BoneFlute]

Statický typový systém nemá s testováním nic společného. Historicky vznikl kvůli tomu, aby kompilátor mohl generovat rychlý kompaktní kód. Na návrh programu má poněkud komplikační dopad - návrh musí být podřízen statickému typování, ale bez něj by byl jednodušší.

Unit testy píšu kvůli testování funkčnosti, ne kvůli ověřování typů. Pokud budu mít kupř. za úkol napsat nějaký grafový algoritmus, tak unit testem zkouším, zda funguje tak jak má, a ne jestli tam jdou "správné" typy. Statická typová kontrola, jak se zdá, v někom vzbuzuje falešný pocit, že je to nějaký test navíc. Ale to není! Statická typová kontrola mi hází při kompilaci chyby, které tam jsou, jen protože se vyžaduje statická typovost. Je to tak trochu začarovaný kruh. Na jednu stranu mě sice zarazí, pokud omylem použiju nějakou proměnnou na něco jiného (samozřejmě tedy jen pokud to má náhodou i jiný typ), ale na druhou stranu mi zase komplikuje práci, když by ta jedna proměnná klidně mohla obsahovat různorodá data.

Nechci hodnotit, co je lepší nebo horší, obojí má podle mě své místo a opodstatnění. Ale statické typování rozhodně žádné unit testování nenahrazuje.
(osobně mi statické typování překáží tím více, na čím vyšší úrovni abstrakce se pohybáváuji; na low-level záležitosti mi připadá jako naprosto perfektní)

Obávám se, že žijem každý úplně v jiném světě.

[BoneFlute]

Stalo se mi, že:

Psal jsem kód, kde se řadil strom (uzel, mající n potomků). Každý prvek v seznamu potomků měl být seřazen. Psal jsem na to testy asi tejden. Vždycky všechno prošlo, dal jsem na review, a poslali mi to zpět, že za těchto a těchto okolností to padá.
Pak jsem se dožral a napsal jsem si generátor všech možností - tedy dle mého chápání něco jako statický typ. Pak to půl hodiny chroupalo, vyhodilo pět chybujících scénářů, ty jsem zohlednil a byl klid.

Psal jsem parser. Unittesty jsou samozřejmě na to jak stvořené. Všechno krásně přímočaré, supr. Pochvaloval jsem si, jak umím krásně psát testy. A pak jsem si uvědomil, že jsem idiot. Kdyžbych napsal jen specifikaci toho formátu, a napsal na to generátor, tak se s tím nemusím tak patlat.

Tak jasně, u typů se musí víc přemýšlet. Ale nerad bych odbočoval do těchto bažin.

Rád bych v tomto vláknu ještě pár ukázek nějakého kódu, kde si typy nabijou hubu. Zatím uvedl Gödel uvedl ty prvočísla. To máme jeden. Napadá vás něco dalšího?

[Ondra Satai Nekola]

Pak jsem se dožral a napsal jsem si generátor všech možností - tedy dle mého chápání něco jako statický typ.

Tak to je nejake divne chapani...

[Kit]

Celé mi to připadá jako souboj mezi funkcionálním a objektovým programováním. Zatímco funkcionální jazyky se opírají zejména o typy a dokazování správnosti, objektové jazyky se opírají zejména o testy. V tomto kontextu se nedá rozhodnout, co z nich je lepší.

Otázku bych tedy rozdělil na dvě:

• Myslíte si, že ve funkcionálním jazyce, ve kterém máte kvalitní typový systém, jsou potřebné jednotkové testy?
• Myslíte si, že v objektovém jazyce, ve kterém máte jednotkové testy, je potřebný typový systém?

[Ondra Satai Nekola]

Zatímco funkcionální jazyky se opírají zejména o typy a dokazování správnosti

Napriklad lisp nebo lambda calculus, co?

• Myslíte si, že ve funkcionálním jazyce, ve kterém máte kvalitní typový systém, jsou potřebné jednotkové testy?
• Myslíte si, že v objektovém jazyce, ve kterém máte jednotkové testy, je potřebný typový systém?

Ano a ano. Protoze jedno umi snadno resit problemy, ktere to druhe nezvladne nebo zvladne bolestive.

[gll]

Tak ono jaksi uz v principu typy resi (ne nutne dost zevrubnou) kontrolu pro vsechny mozne hodnoty, zatimco testy jenom pro nejake konkretni (at uz zadane nebo v pripade property based testu generovane) hodnoty.

ta kontrola může být dost komplikovaná. Samotnou definici typu potom musíte testovat na nějakých konkrétních hodnotách. Napadá mě třeba typ reprezentující číslo kreditní karty. Je docela jedno, jestli je validace součástí typu nebo v samostatné funkci.

[BoneFlute]

Pak jsem se dožral a napsal jsem si generátor všech možností - tedy dle mého chápání něco jako statický typ.

Tak to je nejake divne chapani...

Tak samozřejmě :-) Ber to prosím s rezervou.

Já si z typů beru to, že
- jsou deklarativní (a ideálně expresivní) - deklarativní s důrazem na "popisné"
- jsou ultimátní, tedy pokrývají všechny scénáře
- počítá to stroj
- a samozřejmě nesmíme zapomenout na záruky

Dále jsem se poučil studiem nějakých věcí, že typy jsou mnohem víc, než to, co nám ukazuje Java. A snažím se zchladit své nadšení hledáním, kde to má hranice. Protože zatím všechny případy nějaké logiky, které mě napadali tak se při troše fantazie dali typy popsat.

[BoneFlute]

Tak ono jaksi uz v principu typy resi (ne nutne dost zevrubnou) kontrolu pro vsechny mozne hodnoty, zatimco testy jenom pro nejake konkretni (at uz zadane nebo v pripade property based testu generovane) hodnoty.

ta kontrola může být dost komplikovaná. Samotnou definici typu potom musíte testovat na nějakých konkrétních hodnotách. Napadá mě třeba typ reprezentující číslo kreditní karty. Je docela jedno, jestli je validace součástí typu nebo v samostatné funkci.

Co na té kartě chceš testovat?