Typový system versus unittesty

[SB]

...V unittestech otestuju pár jednoduchých případů a mám celkem jistotu.

Jistotu nemáte, ale i jednoduchým(!) testem můžete zachytit ty největší průsery či totální nefunkčnosti (pravděpodobnost, že chybějící implementace či metoda vám vrátí správný výsledek, je nula hovno), v případě pouhých několika specifických testů dokážete dosáhnout řádově větší protestovanosti než POUHOU typovou kontrolou (kterou můžete úplně klidně též do testu u netypového jazyku doplnit!).

Mimochodem v TDD je pravidlem, že se píší vybrakované metody, které se teprve na stížnost hotových testů vyplňují, případně (a teď pozor, soudruzi javaři nečtěte dále, aby vám z toho nehráblo) se tyto metody teprve vytvářejí! :O :O :O (No nekecej!)

Tohle není odpověď pro JSH, ale autora dotazu Boneflute.

[Reklama]

[v]

Tak jinak: Doplňuju svůj původní příspěvek:

místo <cokoliv> je "return 10"

Typově je vše správně, ale nějak nám to pro většinu vstupů nevychází, přičemž by to mělo vyjít alespoň pro ty, které budu používat.

Přeloženo: Typová kontrola by zafungovala pouze v případě, že pro každé dva sčítance a součet budete mít extra typy, což je ale v rozporu s jednoduchými, obecnými kategoriemi (zde celá čísla) a prakticky to neřeší problém.

s použitím techniky o které jsem mluvil by se takový kód nepřeložil, že má třeba 1 a 2 jiný datový typ není nic až tak zvláštního

[Filip Jirsák]

používá to peanovu aritmetiku na typové úrovni pro vynucení vlastností operací s vektorama (ve smyslu datové struktury), např. tahle funkce je vlastně to stejné jako sčítání:
append :: Vector a n -> Vector a m -> Vector a (n :+ m)
délka výsledného vektoru je součet délek vstupních vektorů (a typový systém to opravdu na implementaci vynutí)

Stále se míjíte s podstatou problému. V mém příkladu bylo záměrně sčítání a odčítání. Abyste si uvědomil, že v běžném programu budu potřebovat obojí, a žádný typový systém neohlídá to, že nepoužiju odčítání tam, kde z logiky věci má být sčítání.

[v]

používá to peanovu aritmetiku na typové úrovni pro vynucení vlastností operací s vektorama (ve smyslu datové struktury), např. tahle funkce je vlastně to stejné jako sčítání:
append :: Vector a n -> Vector a m -> Vector a (n :+ m)
délka výsledného vektoru je součet délek vstupních vektorů (a typový systém to opravdu na implementaci vynutí)

1) Ten typ ale vůbec nezaručuje, že ten append dělá to, co chceme. Ten typ je kompatibilní se spoustou věcí od appendu v libovolném pořadí až po nějaké pseudonáhodné promíchání.
2) V reálných programech se obvykle počet prvků dovídám až v runtimu.
3) A jak to vůbec souvisí s tím, jestli kód odpovídá řešenému problému?

1) to je pravda a nevím jak to řešit, pro sčítání to ovšem nehraje roli
2) to se dá řešit
3) typ specifikuje co je řešený problém, funkce tomu musí odpovídat

[v]

používá to peanovu aritmetiku na typové úrovni pro vynucení vlastností operací s vektorama (ve smyslu datové struktury), např. tahle funkce je vlastně to stejné jako sčítání:
append :: Vector a n -> Vector a m -> Vector a (n :+ m)
délka výsledného vektoru je součet délek vstupních vektorů (a typový systém to opravdu na implementaci vynutí)

Stále se míjíte s podstatou problému. V mém příkladu bylo záměrně sčítání a odčítání. Abyste si uvědomil, že v běžném programu budu potřebovat obojí, a žádný typový systém neohlídá to, že nepoužiju odčítání tam, kde z logiky věci má být sčítání.

tak když někdo špatně pochopí problém, tak mu taky nic nezabrání napsat chybný test

[Reklama]

[Filip Jirsák]

s použitím techniky o které jsem mluvil by se takový kód nepřeložil, že má třeba 1 a 2 jiný datový typ není nic až tak zvláštního

Jak zabráníte tomu, aby programátor nepoužil špatný typ? Místo typu pro „sčítání“ použije typ pro „odčítání“.

[JSH]

s použitím techniky o které jsem mluvil by se takový kód nepřeložil, že má třeba 1 a 2 jiný datový typ není nic až tak zvláštního

A k čemu to je, když většina numerických hodnot, se kterýma se pracuje, je k dispozici až v runtime? Na zkontrolování čísel, která znám při kompilaci, obvykle stačí blbý static_assert či něco podobného.

[Filip Jirsák]

tak když někdo špatně pochopí problém, tak mu taky nic nezabrání napsat chybný test

To je ale nepochopení testů. Testy nemají opakovat implementaci, testy mají kontrolovat, zda pro zadaný vstup dostanu očekávaný výstup.

Nikdo netvrdil, že testy jsou dokonalé a že nemůže být chyba i v testu. Pouze vyvracíme tvrzení, že jednotkové testy lze plně nahradit silným typovým systémem. Vyvráceno to bylo triviálním příkladem, kdy programátor použije odčítání místo sčítání, a tomu žádný typový systém z logiky věci nemůže zabránit.

[Harik]

Sorry, tvé příspěvky nejsou vůbec inspirativní. Nebudu se tedy tebou již zabejvat.

Jirsák a nobody 

[v]

s použitím techniky o které jsem mluvil by se takový kód nepřeložil, že má třeba 1 a 2 jiný datový typ není nic až tak zvláštního

A k čemu to je, když většina numerických hodnot, se kterýma se pracuje, je k dispozici až v runtime? Na zkontrolování čísel, která znám při kompilaci, obvykle stačí blbý static_assert či něco podobného.

nekontrolují se konkrétní čísla (typicky), ale funkce, které s nimi pracují, např. ten příklad se sčítáním tvrdí, že předpoklad z typu je splněn pro všechna čísla (Nat)

[v]

tak když někdo špatně pochopí problém, tak mu taky nic nezabrání napsat chybný test

To je ale nepochopení testů. Testy nemají opakovat implementaci, testy mají kontrolovat, zda pro zadaný vstup dostanu očekávaný výstup.

Nikdo netvrdil, že testy jsou dokonalé a že nemůže být chyba i v testu. Pouze vyvracíme tvrzení, že jednotkové testy lze plně nahradit silným typovým systémem. Vyvráceno to bylo triviálním příkladem, kdy programátor použije odčítání místo sčítání, a tomu žádný typový systém z logiky věci nemůže zabránit.

já jsem ale o opakování implementace nic nepsal, pokud špatně pochopíte problém, můžete napsat test, který od funkce chce pro zadané vstupy jiné výstupy, než ty správné (z hlediska řešeného problému)
a prosím přestaňte si domýšlet obsah příspěvků, pokud máte pochybnosti tak se prostě zeptejte

[SB]

tak když někdo špatně pochopí problém, tak mu taky nic nezabrání napsat chybný test

To už ale nemá co dělat s problematikou testování, ale chápání řešené úlohy, zde nevznikne rozdíl při použití typového systému, nebo testů.

[v]

tak když někdo špatně pochopí problém, tak mu taky nic nezabrání napsat chybný test

To už ale nemá co dělat s problematikou testování, ale chápání řešené úlohy, zde nevznikne rozdíl při použití typového systému, nebo testů.

souhlasím

[Kit]

...V unittestech otestuju pár jednoduchých případů a mám celkem jistotu.

Jistotu nemáte, ale i jednoduchým(!) testem můžete zachytit ty největší průsery či totální nefunkčnosti (pravděpodobnost, že chybějící implementace či metoda vám vrátí správný výsledek, je nula hovno), v případě pouhých několika specifických testů dokážete dosáhnout řádově větší protestovanosti než POUHOU typovou kontrolou (kterou můžete úplně klidně též do testu u netypového jazyku doplnit!).

Ty testy se nepíší náhodně, ale testují se hlavně okrajové podmínky, kdy testovaná jednotka může selhat nebo musí selhat.

Mimochodem v TDD je pravidlem, že se píší vybrakované metody, které se teprve na stížnost hotových testů vyplňují, případně (a teď pozor, soudruzi javaři nečtěte dále, aby vám z toho nehráblo) se tyto metody teprve vytvářejí! :O :O :O (No nekecej!)

Má to svůj důvod. Pokud vytvořím test, který neselže, je to problém, který se musí vyřešit dříve, než napíši první znak testované jednotky. Může to být způsobeno například kolizí názvů, takže ten test testuje jinou jednotku téhož jména, která náhodou také projde.

Pak teprve napíši ty prázdné metody, které musí splnit definované rozhraní. Až testy projdou, teprve je čas na rozšíření testů o požadované funkcionality a následně i rozšíření metod.

[Kit]

Stále se míjíte s podstatou problému. V mém příkladu bylo záměrně sčítání a odčítání. Abyste si uvědomil, že v běžném programu budu potřebovat obojí, a žádný typový systém neohlídá to, že nepoužiju odčítání tam, kde z logiky věci má být sčítání.

tak když někdo špatně pochopí problém, tak mu taky nic nezabrání napsat chybný test

Jistě, ale vcelku brzy zjistí, že ten test je chybný. Testy na testy se však nepíší, od toho tu jsou testované jednotky.