Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - BoneFlute

Stran: 1 ... 86 87 [88] 89 90 ... 133
1306
Vývoj / Re:Typový system versus unittesty
« kdy: 27. 06. 2018, 14:03:49 »
Pokryti testy asi vetsina lidi chape jako (mnozstvi kodu spusteneho behem testovani)/(celkove mnozstvi kodu) a ne jako (mnozstvi testovanych vstupu)/(mnozstvi vsech moznych vstupu).
To, že otestuju tři hodnoty, a prohlásím, že kód je otestovaný, přičemž u čtvrté hodnoty to chcípne, to je poněkud smutné, nemyslíš?
Ale jo, ale to pokryti zajima spis management nez programatory. Je to nejaka metrika ktere si mysli, ze rozumi. Ja na svem projektu rozhodne zadne pokryti nemerim.

Mám na mysli takové to, když vývojář napíše těch pár testů a posílá na produkci. Tím gestem říká, že je to otestované. Nemluvil jsem vysloveně o ceverage.

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.
No já v matematice poněkud plavu, ale měl jsem za to, že ten algoritmus je funkce, která počítá hodnoty, ze kterých se dá udělat taková ta křivka ukazující charakteristiku, jak ty hodnoty jdou.
Asi bych si dovedl představit, že někdo bude "programovat" funkci tím, že ji myší vytáhne v nějakém prostoru, a kompiler z toho odvodí funkci. Ale nedovedu si představit, že by to bylo praktické.

Četl jsem zajímavej článek o tom, že máme matematiku řeckou, založenou na algoritmu, a babylonskou, založenou na tabulce (třeba takové ty tabulky odmocnin, co nám dávali na základce).

Máme reálnou množinu všech možných trojúhelníků.
Babyloňan z té množiny udělá podmnožinu několika pravoúhlých trojúhelníků, a tobě to musí stačit. Pythagoras vymyslí vzorec, kterým vytáhne libovolný pravúhlý trojúhelník jen na základě argumentů (vytvoří funktor? mezi množinou trojúhelníků a množinou těch argumentů).

Na tom typování je vtipné právě to, že na rozdíl od testování se pokouší o vytvoření těch ultimátních vzorečků díky kterým dosáhnu ultimátní jistoty.

1307
Vývoj / Re:Typový system versus unittesty
« kdy: 26. 06. 2018, 23:52:17 »
https://gist.github.com/ondrap/69fa2162bc2516469642e5380b379f5c (v reálu by tam byl zvlášť typ na operátor a Show instance pro jednodušší debugování, která se bohužel u toho ExprF nenageneruje sama)

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...

Moc pěkný. Díky!

1308
Vývoj / Re:Typový system versus unittesty
« kdy: 26. 06. 2018, 22:57:53 »
Pokryti testy asi vetsina lidi chape jako (mnozstvi kodu spusteneho behem testovani)/(celkove mnozstvi kodu) a ne jako (mnozstvi testovanych vstupu)/(mnozstvi vsech moznych vstupu).
To, že otestuju tři hodnoty, a prohlásím, že kód je otestovaný, přičemž u čtvrté hodnoty to chcípne, to je poněkud smutné, nemyslíš?

Nicmene tvuj priklad krasne ukazuje, ze pri pouziti vhodnych typu ztraci smysl vsechny negativni testy. A nejen smysl, ale vlastne ani nejdou napsat/spustit, protoze ta typovane verze funkce proste nejde zavolat s jinym typem argumentu.
Tak :-)

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?

1309
Vývoj / Re:Typový system versus unittesty
« kdy: 26. 06. 2018, 15:09:31 »
...v případě Typového systému máme 100% pokrytí z principu vždy...

Nikoho tu tato věta nevydráždila...?
Tak povídej :-)
Pokryti ceho a cim?

Měl jsem na mysli trivialitu v tom, že:
Kód: [Vybrat]
fn foo(Byte: x):

je ekvivalentní:

Kód: [Vybrat]
fn foo(x):

fn test_foo():
    foreach x in [0, 1, 2, 3, 4, 5 , 6, ... 255]:
        foo(x)

fn test_foo_fail_string():
    foreach x in ["a", "b", "c", ... "aa", "bb", ...]:
        exceptedException
        foo(x)

fn test_foo_fail_float():
    foreach x in [1.1, 1.2, 1.3, ...]:
        exceptedException
        foo(x)

a vlastně ten rozvoj je nekonečný...

1310
Vývoj / Re:Typový system versus unittesty
« kdy: 26. 06. 2018, 14:49:50 »
Ani jsi nedefinoval, že vstupy musí být int nebo string. Nic. Není tedy co testovat.
Počkej, počkej, máš to otestovat. Ne typovat. Hezky si to otestuj bez použití typů :-P

1311
Vývoj / Re:Typový system versus unittesty
« kdy: 26. 06. 2018, 14:48:08 »
...v případě Typového systému máme 100% pokrytí z principu vždy...

Nikoho tu tato věta nevydráždila...?
Tak povídej :-)

1312
Vývoj / Re:Typový system versus unittesty
« kdy: 26. 06. 2018, 14:17:08 »
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 :-)

1313
Vývoj / Re:Typový system versus unittesty
« kdy: 26. 06. 2018, 14:15:04 »
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.

1314
Vývoj / Re:Typový system versus unittesty
« kdy: 26. 06. 2018, 14:05:26 »
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.

1315
Vývoj / Re:Typový system versus unittesty
« kdy: 25. 06. 2018, 23:52:34 »
Nemám sílu to už sledovat, takže se omlouvám, pokud něco opakuji.

Osobně vidím rozdíl mezi unittestem a kontrolu pomocí typového systémem tak, jak je zde popsán. Zatímco typový systém určuje omezení, kterým podléhá výsledek, unit test specifikuje vstupy a pro něj správný výstup. Rozumím tomu, že typový popis vypadá velmi elegantně a zachycuje všechny možné hodnoty. Ale nastavit správný typ pro komplexní funkce nemusí být triviální a může se v něm zrcadlit algoritmus výpočtu, což může snadno zanést chybu. Naproti tomu unit test, jakkoliv zachytí jen velmi omezenou množinu možných hodnot, je triviální - vstupy a požadovaný výstup. Možnost chyby velmi omezená. A proto se budou typový systém a unit testy, IMHO, vždy doplňovat. Čím dokonalejší typový systém, tím může být unit tetsů méně, ale nemyslím si, že je možné je zcela pominout. Chyba může vzniknout nejen při programování funkce, ale i při definici typu.
Rozumím. Ale chyba může vzniknout i při psaní testu. Vzhledem k tomu, jak často zoufale nečitelné mohou testy být - velmi snadno.

Jednou se mi stalo, že jsem našel chybu v kódu, který měl stoprocentní pokrytí testy. Byl to den, kdy jsem na coverage zanevřel.

1316
Vývoj / Re:Typový system versus unittesty
« kdy: 25. 06. 2018, 23:26:21 »
To bych se načekal. Někdy spouštím testy i 3× za minutu.
Podle me nepoustis testy, ale aparatus. Aparatus zajisti, ze se prelozi "jednotka" (pricemz probehne typova kontrola) pak se prelozi test a nakonec se test spusti. Takze unit test se spusti (tesne) po prekladu, ale rozhodne ne pri nem.

Konečně to někdo pochopil :)

Jednotkové testy už prostě používám jako druhou fázi kompilace.
Až na to, že to kompilace není, protože nic nekompiluješ. No nic, log-off.

1317
Vývoj / Re:Typový system versus unittesty
« kdy: 25. 06. 2018, 23:12:49 »
Nejprve spustím test, ten spustí kompilaci jednotky a otestuje ji. Test tedy spouštím při překladu nebo ne?
Ne. Testy se spouští při buildu. Build a compile není to samé.

To bych se načekal. Někdy spouštím testy i 3× za minutu.
Podle me nepoustis testy, ale aparatus. Aparatus zajisti, ze se prelozi "jednotka" (pricemz probehne typova kontrola) pak se prelozi test a nakonec se test spusti. Takze unit test se spusti (tesne) po prekladu, ale rozhodne ne pri nem.
Sleduj. Teď zase odskočí někam jinam.

1318
Vývoj / Re:Typový system versus unittesty
« kdy: 25. 06. 2018, 23:11:35 »
Nejprve spustím test, ten spustí kompilaci jednotky a otestuje ji. Test tedy spouštím při překladu nebo ne?
Ne. Testy se spouští při buildu. Build a compile není to samé.

To bych se načekal. Někdy spouštím testy i 3× za minutu.

No a?

1319
Vývoj / Re:Typový system versus unittesty
« kdy: 25. 06. 2018, 21:44:16 »
Unit testy se neprovádí v době překladu, na rozdíl od typové kontroly.
Kdy jindy bys chtěl dělat jednotkové testy, než při překladu?
Jednotkové testy jsou kód jako každý jiný, normálně se přeloží (compile time) a spustí (run time). Typová kontrola probíhá při překladu nad oanotovaným syntaktickým stromem.

Nejprve spustím test, ten spustí kompilaci jednotky a otestuje ji. Test tedy spouštím při překladu nebo ne?
Ne. Testy se spouští při buildu. Build a compile není to samé.

1320
Vývoj / Re:Typový system versus unittesty
« kdy: 25. 06. 2018, 16:47:24 »
Akorát teda pak zápis těch podmínek nebude moc připomínat typování, spíš nějaký lambda kalkul.
Tak jak sis mohl všimnout, pro mnohé jsou Java typy vrchol toho co znají.

Jak jsem už uváděl. Pro mě je pro ty typy zásadní, že jsou deklarativní. Popisují a "vysvětlují" to kompilátoru, co to má být. Jestli to napíšeš tak či onak, je IMHO nepodstatné. Někdy si pomáhám slovíčkem "pravidla". Definuju pravidla, kterým ten element musí odpovídat, aby to označil za korektní. A ty pravdla samozřejmě nemusí být jen o "je" a "má", ale můžou být klidně docela komplexní. Klidně to je naféráka jazyk. Akorád nepoučuješ procesor, co má udělat, ale kompilátor, co má ten graf programu znamenat. V čemž vidím rozdíl oproti unittestů. Ty obvykle nejsou tak deklarativní, a hlavně compilátoru nepomáhají.


Stran: 1 ... 86 87 [88] 89 90 ... 133