Typový system versus unittesty

[v]

Jinak pokud jde o XSS, tak bych neřekl, že je to principálně věc typů.

Beru zpět, ano XSS jde řešit typy a zrovna docela hezky.

odkaz by nebyl?

[Reklama]

[listoper]

Pak je podstatná ještě jedna věc, která tu zatím moc nebyla zmíněna, a to je to, že typový systém může něco užitečného přinést jedině tehdy, když se používá, tedy když ho programátoři chtějí používat. Stačí se podívat na takové malinké vylepšení hloupého typového systému Javy, jakým jsou kontrolované výjimky. Ani tohle drobné typové omezení se prakticky neujalo, a to je velmi jednoduché kontrolované výjimky jak definovat, tak používat. I to připadá většině Java vývojářů jako zbytečně moc práce v porovnání s jejím přínosem. Takže navrhovat nové typy pro masové použití klidně můžete, ale pak se vám také klidně může stát, že budou vznikat a široce se používat knihovny, které budou jako jednu ze svých důležitých vlastností uvádět to, že ruší ten váš typový systém.

Kdyby ten system za neco stal, ve smyslu ze pridana hodnota prevysi overhead ktery prinasi, tak by ho programatori radi pouzivali. Jenze tomu tak v jave prave neni.

[Filip Jirsák]

z jakých materiálů jste čerpal? popř. v jakém jazyce jste to zkoušel?

„Ale to je magnétismus, to je úplně nová fyzika, nechoďte na mně s nějakým zastaralým zákonem o zachování energie. Říkám vám, že mi to funguje, jenom maličko točit klikou musíte, ale to se doladí, to už jsou jenom takové maličkosti, jenom najít ten správný mazací olej…“

[Filip Jirsák]

Máš pravdu, když to píšu, tak to píšu bez přemýšlení... až na to, že tohle je kód, který je dost důsledně kontroluje, jestli ve zdrojových datech nechybí atributy, jestli to pole "delta" je fakt neprázdné, jestli tam někde nejsou nully.... a teď mi řekni, jak bys to psal v dynamickém jazyku a jak by vypadaly unit testy....

Kdybych to psal v dynamickém jazyku, tak asi proto, abych typy nemusel řešit a poradilo si to s co největší škálou různých (i ne zcela správných) vstupů. Podle toho by vypadaly i jednotkové testy – poslal bych do toho JSON, kde by chyběly položky, místo Intu by tam bylo číslo jako text, text nepřevoditelný na číslo, null…

[Filip Jirsák]

Jinak pokud jde o XSS, tak bych neřekl, že je to principálně věc typů.

Beru zpět, ano XSS jde řešit typy a zrovna docela hezky.

odkaz by nebyl?

Jakub Vrána mluvil na Devel.cz o tom, jak to dělají v Googlu – Dokazatelná bezpečnost.

[Reklama]

[v]

z jakých materiálů jste čerpal? popř. v jakém jazyce jste to zkoušel?

„Ale to je magnétismus, to je úplně nová fyzika, nechoďte na mně s nějakým zastaralým zákonem o zachování energie. Říkám vám, že mi to funguje, jenom maličko točit klikou musíte, ale to se doladí, to už jsou jenom takové maličkosti, jenom najít ten správný mazací olej…“

ne magnétismus, "dependent types", jakožto příklad současného stavu věcí

[andy]

Jinak pokud jde o XSS, tak bych neřekl, že je to principálně věc typů.

Beru zpět, ano XSS jde řešit typy a zrovna docela hezky.

odkaz by nebyl?

Nebyl, ale v podstatě to tak řeší všichni - HTML výstup si obalit typem, který lze modifikovat/vytvářet pouze funkcemi, které dělají escaping.

[v]

nuda, ale zjevně funkční

[andy]

Máš pravdu, když to píšu, tak to píšu bez přemýšlení... až na to, že tohle je kód, který je dost důsledně kontroluje, jestli ve zdrojových datech nechybí atributy, jestli to pole "delta" je fakt neprázdné, jestli tam někde nejsou nully.... a teď mi řekni, jak bys to psal v dynamickém jazyku a jak by vypadaly unit testy....

Kdybych to psal v dynamickém jazyku, tak asi proto, abych typy nemusel řešit a poradilo si to s co největší škálou různých (i ne zcela správných) vstupů. Podle toho by vypadaly i jednotkové testy – poslal bych do toho JSON, kde by chyběly položky, místo Intu by tam bylo číslo jako text, text nepřevoditelný na číslo, null…

To by mě zajímalo, proč bys zrovna z těchto důvodů tohle psal v dynamickém jazyku.... kvůli tomu zpracování přece v té výsledné struktuře nakonec stejně chceš "Int" a ne text, a když tam nemá být null, tak stejně musíš kontrolovat, že tam není null...

ale zpět - já fakt nesouhlasím s:

To záleží na kontextu. Pokud se bude pohybovat v kódu, kde bude většina typů non-null, a výjimečně narazí na nullable typ, ošetří to. Pokud bude z venku neustále dostávat nullable typy a použité typy a typový systém ho budou nutit neustále to přetypovávat, bude to dělat automaticky bez přemýšlení.

a řekl bych že výše uvedený příklad ukazuje, že to prostě není pravda.

A ze stejných důvodů nesouhlasím s tímto:

I tenhle typ chyby se bude objevovat u sebelepšího typového systému, protože když programátora nenapadne, že to je zajímavý případ a měl by na to udělat test, nenapadne ho ani ošetřit to v typovém systému.

Protože například u té nullpointerexception je prostě používání "Maybe" typu na úplně jiné úrovni než dávat někam asserty a psát k tomu unit testy. V podstatě je to ekvivalentní těm "model checker" systémům. A dost mi to připomíná toto:

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

[BoneFlute]

Obvykle stačí testovat chování pro limitní a nadlimitní hodnoty vstupů. Testy tak vychází jen asi 2× delší než testovaný kód.

v dynamickém jazce? postněte nějaký jednoduchý příklad (funkce+testy), bylo by zajímavé zkusit co s tím udělá zavedení typů

Zavedení dalších typů s tím neudělá vůbec nic, protože typy nezkoumají funkčnost.

Zkoumají. Už to ty bylo vysvětlováno.

[v]

předpokládejme tu vaši specifikaci ("sečte hodnoty parametrů") a zahoďme moji funkci, jak budou vypadat testy?

Tak především se test nekouká dovnitř, ale zvenčí. A kouká se jen na vlastnosti, které jsou od té funkce požadovány. Pokud je požadavkem "sečíst hodnotu numerických parametrů", tak obvykle stačí třeba:

Kód: [Vybrat]

def testX():
    assert(x(3, 5) == 8)
    assert(x(-3, 5) == 2)
    assert(x(3, -5) == -2)
    assert(x(-3, -5) == -8)

Pokud nebudu mít na vstupu např. záporná čísla, mohu odpovídající testy vypustit. Pokud budu chtít touto funkcí spojvat i řetězce nebo posouvat čas o offset, tak je do testu přidám. Pokud potřebuji, aby funkce při výsledku nad hodnotu 100 vyhodila výjimku nebo ten výsledek ořízla (např. životy u her), tak tam takový test také přidám. Dříve definovaná funkce tím přestane procházet a vývojář ji musí upravit.

Tímto způsobem mohu testovat i cizí knihovny, do kterých nevidím, ale očekávám od nich určité chování pro různé očekávané i méně očekávané vstupy. Pokud její autor změní něco, co bude mít vliv na moji aplikaci, dozvím se to.

dík za doplnění, asi nemá smysl to dál rozebírat, z mojeho pohledu je to slaboučké, nelíbí se mi, že musím doufat, že do toho nikdo nepošle něco s čím jsem nepočítal

[BoneFlute]

100% coverage (kteréhokoliv druhů) samozřejmě možná je, jen je neskutečně drahá pro cokoliv co není triviální aplikace.

Já měl funkci, která byla hlášena jako 100% pokryta. Prostě to už někdo napsal.

Druhak, v případě Typového systému máme 100% pokrytí z principu vždy. A kdo zaplatí tu cenu se posouvá od vývojáře aplikace k architektovi typového systému. A tam se samozřejmě rozhoduje, že něco Typama podchycovat nebudeme, protože něco, a pak se to tedy řeší (a nebo taky často ne) testy.

[BoneFlute]

Halting problem se týká univerzálního algoritmu který by dokázal pro jakýkoliv program s jakýmkoliv vstupem rozhodnout, zda dokončí nebo nedokončí běh. Turing nikdy neřekl, že neexistuje algoritmus, který by pro konkrétní program nedokázal rozhodnout, zda dokončí či nedokončí. To je velký rozdíl.

Zjevně jsi nepřečetl ten odstavec, který jsem doporučoval:

...
V dněšních počítačích a běžných programech je těch stavů ještě o mnoho řádů více. Mnoho štěstí s testováním.

Phi má recht, obecně to nejde, ale ve speciálních (neřešíme ale, jak často!) ano:

class Vědma:
    odpověďNaOtázkuŽivota():
        return 42

testVědmy:
    assert(Vědma().odpověďNaOtázkuŽivota() == 42)

A je to pokryto. Důkaz sporem.

Počkej, počkej, ještě musíš otestovat negativní případy :-)

[Kit]

dík za doplnění, asi nemá smysl to dál rozebírat, z mojeho pohledu je to slaboučké, nelíbí se mi, že musím doufat, že do toho nikdo nepošle něco s čím jsem nepočítal

To nebylo v zadání. Zcela v něm chybělo, jak se ta funkce má chovat, pokud dostane nějaké vstupy, které mají být z nějakého důvodu nevalidní.

[v]

dík za doplnění, asi nemá smysl to dál rozebírat, z mojeho pohledu je to slaboučké, nelíbí se mi, že musím doufat, že do toho nikdo nepošle něco s čím jsem nepočítal

To nebylo v zadání. Zcela v něm chybělo, jak se ta funkce má chovat, pokud dostane nějaké vstupy, které mají být z nějakého důvodu nevalidní.

no právě, jakékoliv podmínky bych vymyslel, furt musím doufat, že volající je dodrží