Typový system versus unittesty

[Kit]

Prosil bych ukázku použití typového systému, ve které není možné provést náhradu jednotkovými testy.

Jedna věc je, zda je to teoreticky možné, druhá věc je, zda opravdu ručně psanými jednotkovými testy pokryjete všechny možnosti.

A snad ještě podstatnější je to, že typový systém používá programátor přímo při psaní (jako dokumentaci) – což je úplně něco jiného, než když bude zkoušet náhodně psát kód a zkoušet, jestli to projde jednotkovými testy.

Ručně psanými testy (resp. generovanými) podchytím nejen typovost, což obslouží jeden test, ale i spoustu dalších možností, například reakce na nevalidní vstupy.

Jednotkové testy jsou součástí dokumentace. Jsou zárukou, že jednotka funguje jak má. Tohle typy nedokáží.

[Reklama]

[BoneFlute]

Jednotkové testy jsou součástí dokumentace. Jsou zárukou, že jednotka funguje jak má. Tohle typy nedokáží.

Naopak: http://elm-lang.org - elm-package diff elm-lang/core 3.0.0 4.0.0

[BoneFlute]

Prosil bych ukázku použití typového systému, ve které není možné provést náhradu jednotkovými testy.

Jak to souvisí s mojí otázkou?

[Filip Jirsák]

Ručně psanými testy (resp. generovanými) podchytím nejen typovost, což obslouží jeden test, ale i spoustu dalších možností, například reakce na nevalidní vstupy.

Jednotkové testy jsou součástí dokumentace. Jsou zárukou, že jednotka funguje jak má. Tohle typy nedokáží.

S tím, že jsou testy součástí dokumentace, nesouhlasím. Ano, typy nedokáží to, co dokáží testy – to navrhoval jen BoneFlute a myslím, že už to bylo vyvráceno.

Já bych pod klasickou testovací pyramidu přidal další vrstvu – typový systém. Platí pro to pak stále to, co pro samotnou pyramidu – to, co je vespod, je nejjednodušší, je toho tudíž nejvíc a nejrychleji to odhalí chybu. Takže co jde, pokryje se typovým systémem, když to nejde pokrýt typy, napíšou se na to jednotkové testy, když to nejde řešit jednotkovými testy, napíšou se funkční testy atd.

[BoneFlute]

Ano, typy nedokáží to, co dokáží testy – to navrhoval jen BoneFlute a myslím, že už to bylo vyvráceno.

Kde?

Jsem doufal, že se dozvím nějaké inspirativní podněty. Ne, že to prostě jen smeteš ze stolu.

[Reklama]

[Ondra Satai Nekola]

Ano, typy nedokáží to, co dokáží testy – to navrhoval jen BoneFlute a myslím, že už to bylo vyvráceno.

Kde?

Jsem doufal, že se dozvím nějaké inspirativní podněty. Ne, že to prostě jen smeteš ze stolu.

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.

Tohle samozrejme neni realny produkcni kod, ale jenom vydestilovany jeden z moznych problemu (misto toho random si predstav trebas neco, co zavisi na stavu konkretniho stroje, na kterem to bezi, neco, co zavisi na case atp.):

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

[Filip Jirsák]

Kde?

Hned v komentáři #6.

Jsem doufal, že se dozvím nějaké inspirativní podněty. Ne, že to prostě jen smeteš ze stolu.

Nesmetl jsem to ze stolu, jenom mi připadá zbytečné opakovat, co už bylo řečeno a je triviální.

[Kit]

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

[BoneFlute]

Ano, typy nedokáží to, co dokáží testy – to navrhoval jen BoneFlute a myslím, že už to bylo vyvráceno.

Kde?

Jsem doufal, že se dozvím nějaké inspirativní podněty. Ne, že to prostě jen smeteš ze stolu.

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.

Tohle samozrejme neni realny produkcni kod, ale jenom vydestilovany jeden z moznych problemu (misto toho random si predstav trebas neco, co zavisi na stavu konkretniho stroje, na kterem to bezi, neco, co zavisi na case atp.):

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

Ah, tak teď jsem si naběhl. Jsem tu větu pochopil přesně naopak, že Filip Jirsák tvrdí, že bylo vyvráceno, že by typová kontrola nedokázala plně nahradit testy.

[BoneFlute]

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

To by nebyl problém. Typy by vyžadovali nějakou monádu, nebo effect, a podle toho pokračovali s tím, zda se to počítá dobře.

[BoneFlute]

Kde?

Hned v komentáři #6.

To těžko. Je tam tvrzení, ne vysvětlení. Viz následující komentáře.

Jsem doufal, že se dozvím nějaké inspirativní podněty. Ne, že to prostě jen smeteš ze stolu.

Nesmetl jsem to ze stolu, jenom mi připadá zbytečné opakovat, co už bylo řečeno a je triviální.

Ano, neboli žádné argumenty, jen tvrzení, a smetení ze stolu.

Když by to bylo triviální, tak předvedeš nějaký pěkný kód. Chci snad tak moc?

[Filip Jirsák]

Ah, tak teď jsem si naběhl. Jsem tu větu pochopil přesně naopak, že Filip Jirsák tvrdí, že bylo vyvráceno, že by typová kontrola nedokázala plně nahradit testy.

Pro pořádek, tvrdím, že typová kontrola nedokáže plně nahradit jednotkové testy (např. nedokáže zkontrolovat algoritmy). Dále jsem reagoval na Kita, že jednotkové testy sice teoreticky mohou nahradit typovou kontrolu (a dělá se to tak u jazyků bez typů), ale prakticky to nikdy nebude úplná kontrola, protože psát jednotkové testy je podstatně náročnější, než používat typy.

[BoneFlute]

Tento příklad mi zrovna přijde celkem na pohodu. Nadefinuju si jednotlivé elementy jsonu, serialize to string. Že to dává smysl zkouknu okem, a pak zafixuju ala Elm.

Tomu asi nerozumím - je poměrně jednoduché vytvořit ToJSON a FromJSON tak, aby to navzájem kompatibilní nebylo. Tak, jak jsou ty typeclassy oddělené, nejde typově zajistit, že to kompatibilní je. Je možné vyrobit ty typy jinak. Nicméně parsing obecně typově kontrolovat nejde - ten soulad se specifikací prostě do typu té funkce

Kód: [Vybrat]

Text -> ParsedValue nenakóduju.

Rozumím.

Kód: [Vybrat]

(toJSON json) -> str == (fromJSON str) -> json by nešlo? Kompiler by musel ověřit, zda všechny varianty stromu, když se vygenerují do stringu a pak následně naparsují jsou shodné.

[Filip Jirsák]

To těžko. Je tam tvrzení, ne vysvětlení. Viz následující komentáře.

Následující komentář je váš dotaz na vysvětlení a hned následující komentář je vysvětlení.

Když by to bylo triviální, tak předvedeš nějaký pěkný kód. Chci snad tak moc?

Vždyť ten kód byl v komentáři odpovídajícím na vaše „Proč?“ Já bych tu funkci akorát jinak nazval, jinak je kód stejný, protože to je první, co každého napadne:

Kód: [Vybrat]

//sečte dvě čísla
int add(int x, int y) {
  return x - y;
}


[BoneFlute]

To těžko. Je tam tvrzení, ne vysvětlení. Viz následující komentáře.

Následující komentář je váš dotaz na vysvětlení a hned následující komentář je vysvětlení.

Když by to bylo triviální, tak předvedeš nějaký pěkný kód. Chci snad tak moc?

Vždyť ten kód byl v komentáři odpovídajícím na vaše „Proč?“ Já bych tu funkci akorát jinak nazval, jinak je kód stejný, protože to je první, co každého napadne:

Kód: [Vybrat]

//sečte dvě čísla
int add(int x, int y) {
  return x - y;
}


A následně bylo poukázáno, že toto by šlo: https://forum.root.cz/index.php?topic=18804.msg270160#msg270160

Prosím něco lepšího :-)