Typový system versus unittesty

[JSH]

Vyvracení není trollení.

Začalo to kultivovaným vyvracením. A to i ze strany Kitta a Jirsáka.

Já nejsem ten, který tu na potkání tvrdí, že ten druhý je úplně blbej, a že tomu nerozumí, a že by měl to a to. Si mě s někým pleteš.

Nepletu. Já napsal něco jiného. Prosím nevkládej mi do příspěvků něco, co tam není.

A co se týče argumentů, byl bych s něčím takovým výrazně méně kategorický. Ano, uznávám, že příspěvky Kita a Filipa Jirsáka nečtu. Určitě chápeš proč.

Minimálně příspěvky Filipa Jirsáka jsi četl a reagoval jsi na ně. A dost arogantně. Např:

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

Ano, jeho argument byl jednoduchý, ale velmi relevantní.

[Reklama]

[BoneFlute]

...

Je vidět, že naše metriky se zásadně liší. To je vše, co k tomu mohu říct.

[listoper]

Proto me se libi treba clojure.spec. I kdyz je clojure dynamicky jazyk tak spec mu pridava neco jako "velmi silny typovy system" (Neni to primo v jazyku takze jsou potreba nejake nastroje na instrumentaci, proto "neco jako"). A krasne to integruje s testcheckem takze tomu muzu rict aby se pri buildu nahodne vygenerovalo bambilion vstupu odpovidajicich SPECifikaci a projelo se to funkci a vyhodnotilo jestli vystup taky odpovida specifikaci(a do znacne miry i jestli je spravne vzhledem ke konkretnim vstupum). Takze nemusim napsat jedinny unit test a mam pokryto radove lepe nez s unit testy.

Domnívám se, že v tomto případě jde spíše o automaticky generované testy. Což je taky dobrý. Ale typy jsou imho o něčem jiném. Viz ta ukázka https://forum.root.cz/index.php?topic=18804.msg271719#msg271719

Můžeš udělat typy, které se budou checkovat třeba týden. Ale udělat testy na bambilion vstupů budou ještě mnohem horší s horší efektivitou.

Ja to vidim nekde mezi. V clojure (ale i v dalsich lispech) je totiz "write time" = runtime. To znamena, ze kazdy vyraz ktery napisu hned evaluuju a mam ho k dispozici v bezicim REPLu. Takze kdyz treba pisu funkci a jeji specifikaci viz https://clojure.org/guides/spec#_spec_ing_functions  muzu klidne tam kde ji volam pomoci valid? nebo conform overit jestli je dane volani odpovida specifikaci. A kdyz si to budu nechavat instrumentovat abych to nemusel zkouset rucne tak se blizim typovemu systemu. (popravde ja to tak nedelam, ale ja taky uz dneska moc kodu nenapisu...)

To ze z toho generuju testy je side effect, ale velmi prijemny. Podle me to prave preklenuje tu mezeru kterou zpusobuji prakticka omezeni na strane unit testu a typoveho systemu. Tam kde by typova specifikace zacinala byt neprakticka a pri tom nebyla kriticka muzu nechat generator chroustat misto abych ja musel cucat z prstu hodnoty ktere se maji vyzkouset.

[BoneFlute]

Proto me se libi treba clojure.spec. I kdyz je clojure dynamicky jazyk tak spec mu pridava neco jako "velmi silny typovy system" (Neni to primo v jazyku takze jsou potreba nejake nastroje na instrumentaci, proto "neco jako"). A krasne to integruje s testcheckem takze tomu muzu rict aby se pri buildu nahodne vygenerovalo bambilion vstupu odpovidajicich SPECifikaci a projelo se to funkci a vyhodnotilo jestli vystup taky odpovida specifikaci(a do znacne miry i jestli je spravne vzhledem ke konkretnim vstupum). Takze nemusim napsat jedinny unit test a mam pokryto radove lepe nez s unit testy.

Domnívám se, že v tomto případě jde spíše o automaticky generované testy. Což je taky dobrý. Ale typy jsou imho o něčem jiném. Viz ta ukázka https://forum.root.cz/index.php?topic=18804.msg271719#msg271719

Můžeš udělat typy, které se budou checkovat třeba týden. Ale udělat testy na bambilion vstupů budou ještě mnohem horší s horší efektivitou.

Ja to vidim nekde mezi. V clojure (ale i v dalsich lispech) je totiz "write time" = runtime. To znamena, ze kazdy vyraz ktery napisu hned evaluuju a mam ho k dispozici v bezicim REPLu. Takze kdyz treba pisu funkci a jeji specifikaci viz https://clojure.org/guides/spec#_spec_ing_functions  muzu klidne tam kde ji volam pomoci valid? nebo conform overit jestli je dane volani odpovida specifikaci. A kdyz si to budu nechavat instrumentovat abych to nemusel zkouset rucne tak se blizim typovemu systemu. (popravde ja to tak nedelam, ale ja taky uz dneska moc kodu nenapisu...)

Já jsem to clojure spec viděl zatím jen z rychlíku (princip REPL ale znám). Když si tedy trochu zaspekuluju: buť tam tedy narve kontrolu na typ, něco jako (v jiném jazyce, chápu že v lispu se to zapíše jinak):

Kód: [Vybrat]

fn inc(a):
    assert(a, "int:1..100")
    ...
případně tam můžu narvat klasickej test aka:

Kód: [Vybrat]

fn inc(a):
    ...
with:
    assert inc(1) == 2
    assert inc(99) == 100

nebo

Kód: [Vybrat]

fn inc(a):
    ...
with:
    foreach x in datasample.rangeint(1..100):
        assert inc(x) == x + 1

Tak nějak?

V prvém případě se to chová jako typ s tím, že blbě vytáhnu signaturu tý funkce (což je ale asi jen otázka řešení toho spec-u, nikoliv principielní problém). V tom druhém a třetím případě je to klasický unittest s výhodami a nevýhodami, které testy mají.

Na druhou stranu je to kompaktní :-)

Výhodu toho spec-u bych viděl v tom, že by měl být deklarativní, tudíž čitelnější než klasické testy, a dají se na to udělat nějaká vizualizovátka, metriky a podobně. Souhlas?

To ze z toho generuju testy je side effect, ale velmi prijemny. Podle me to prave preklenuje tu mezeru kterou zpusobuji prakticka omezeni na strane unit testu a typoveho systemu. Tam kde by typova specifikace zacinala byt neprakticka a pri tom nebyla kriticka muzu nechat generator chroustat misto abych ja musel cucat z prstu hodnoty ktere se maji vyzkouset.

Tak já se obecně domnívám, že ruční psaní unittestů je jen mezistupeň a v budocnosti to nahradí automatika.

Jestli tě chápu dobře - u typů je někdy blbá ta ultimátnost. Že člověku se prostě někdy hodí tu kontrolu vypnout (ve výsledku často zjistí, že to byl blbej nápad, ale což). Nebo že vyžaduje příliš přemýšlení, když potřebuju jen něco vyzkoušet.

[listoper]

V prvém případě se to chová jako typ s tím, že blbě vytáhnu signaturu tý funkce (což je ale asi jen otázka řešení toho spec-u, nikoliv principielní problém). V tom druhém a třetím případě je to klasický unittest s výhodami a nevýhodami, které testy mají.

Na druhou stranu je to kompaktní :-)

Podle me spis prvni pripad:

Kód: [Vybrat]

(ns spec-example.core
  (:require [clojure.spec.alpha :as s]
            [clojure.spec.test.alpha :as stest])
  (:gen-class))

;; definuju predikat a ulozim do registru => znovupouzitelnost
;; taky je videt ze to hezky komponuje skladam predikat z mensich predikatu
(s/def ::small-pos-int (s/and pos-int? #(<= % 100)))

;; definice funkce
(defn -inc
  [a]
  (+ a 1))
;; specifikace ktera zatim nic nedela
(s/fdef -inc
  :args  (s/cat :a ::small-pos-int)  ;; validace vstupu
  :ret pos-int?                      ;; validace vystupu
  :fn #(> (:ret %) (-> % :args :a))) ;; trivialni a neuplna validace vystupu vzhledem ke vstupum

;; zapnu instrumentaci
;; od ted se budou pred exekuci funkce validovat vstupy
;; :ret a :fn samozrejme vyzaduje aby byla funkce provedena,
;; protoze potrebuju navratovou hodnotu
;; takze to uz spada spis do testu nez do typu
(stest/instrument `-inc)

;; nekde v kodu budu chti funkci pouzit
(let [a 105]
  (-inc a))

;; vyhodi mi to:
;;  ExceptionInfo Call to #'spec-example.core/-inc did not conform to spec:
;;  In: [0] val: 105 fails spec: :spec-example.core/small-pos-int at: [:args :a] predicate: (<= % 100)
;;    clojure.core/ex-info (core.clj:4739)
;; drivejsi verze tusim dokonce vyhazovala CompilerException
;; coz mozna jeste vic dava najevo, ze funkce vlastne vubec nebyla spustena


Výhodu toho spec-u bych viděl v tom, že by měl být deklarativní, tudíž čitelnější než klasické testy, a dají se na to udělat nějaká vizualizovátka, metriky a podobně. Souhlas?

Asi uplne nerozumim, ale mozna ze ten priklad na to odpovida sam

To ze z toho generuju testy je side effect, ale velmi prijemny. Podle me to prave preklenuje tu mezeru kterou zpusobuji prakticka omezeni na strane unit testu a typoveho systemu. Tam kde by typova specifikace zacinala byt neprakticka a pri tom nebyla kriticka muzu nechat generator chroustat misto abych ja musel cucat z prstu hodnoty ktere se maji vyzkouset.

Tak já se obecně domnívám, že ruční psaní unittestů je jen mezistupeň a v budocnosti to nahradí automatika.

Cet sem tady na rootu clanek od tisnika o gherkin a domnivam se, ze v budoucnosti budou psat specifikaci testu business analitici ve forme given/when/then a potom uz se toho chytne automat

Jestli tě chápu dobře - u typů je někdy blbá ta ultimátnost. Že člověku se prostě někdy hodí tu kontrolu vypnout (ve výsledku často zjistí, že to byl blbej nápad, ale což). Nebo že vyžaduje příliš přemýšlení, když potřebuju jen něco vyzkoušet.

Spis mam na mysli to premysleni. To nekdy boli.
Takze u nekriticke casti aplikace specifikuju jen do chvile nez to zacne bolet a na zbytek pustim generator testu.

[Reklama]

[BoneFlute]

Kód: [Vybrat]

(ns spec-example.core
  (:require [clojure.spec.alpha :as s]
            [clojure.spec.test.alpha :as stest])
  (:gen-class))

;; definuju predikat a ulozim do registru => znovupouzitelnost
;; taky je videt ze to hezky komponuje skladam predikat z mensich predikatu
(s/def ::small-pos-int (s/and pos-int? #(<= % 100)))

;; definice funkce
(defn -inc
  [a]
  (+ a 1))
;; specifikace ktera zatim nic nedela
(s/fdef -inc
  :args  (s/cat :a ::small-pos-int)  ;; validace vstupu
  :ret pos-int?                      ;; validace vystupu
  :fn #(> (:ret %) (-> % :args :a))) ;; trivialni a neuplna validace vystupu vzhledem ke vstupum

;; zapnu instrumentaci
;; od ted se budou pred exekuci funkce validovat vstupy
;; :ret a :fn samozrejme vyzaduje aby byla funkce provedena,
;; protoze potrebuju navratovou hodnotu
;; takze to uz spada spis do testu nez do typu
(stest/instrument `-inc)

;; nekde v kodu budu chti funkci pouzit
(let [a 105]
  (-inc a))

;; vyhodi mi to:
;;  ExceptionInfo Call to #'spec-example.core/-inc did not conform to spec:
;;  In: [0] val: 105 fails spec: :spec-example.core/small-pos-int at: [:args :a] predicate: (<= % 100)
;;    clojure.core/ex-info (core.clj:4739)
;; drivejsi verze tusim dokonce vyhazovala CompilerException
;; coz mozna jeste vic dava najevo, ze funkce vlastne vubec nebyla spustena


Budu se muset do toho spec-u ponořit. Díky za inspiraci.

[Kiwi]

Jestli tě chápu dobře - u typů je někdy blbá ta ultimátnost.

A co je to vlastně ta "ultimátnost"? S tím slovem jsem se ještě nesetkal.

[Kit]

Tak já se obecně domnívám, že ruční psaní unittestů je jen mezistupeň a v budocnosti to nahradí automatika.

Jednotkové testy, tedy alespoň jejich boilerplates, ve Vimu generuji už dávno. Podobně mi generuje i signatury v Haskellu. Není třeba čekat na budoucnost.

[Kit]

Sorry, ale za to zatrollení diskuze si můžeš IMO primárně sám. Většina téhle diskuze je o tom, že ostatní šijou do tvých kategorických tvrzení.

Ale no tak!

Takže když napíšu "Dospěl jsem k nezdravému přesvědčení, že jednotkové testy nejsou potřeba máte-li kvalitní typový systém." je to přes čáru? A místní smetánka, která věci sice nerozumí, ale má tím pádem právo mě trollit? To jako vážně?!

Není to přes čáru. Je to názor, o kterém tu polemizujeme. Z opačné strany je můj názor, že statický typový systém není potřebný, pokud mám kvalitní testování. Pokud je někdo přesvědčen o svém názoru, musí být připraven na protiargumenty oponentů. Prohrává ten, kdo svého oponenta začne ponižovat, protože to je jasným důkazem, že mu došly argumenty.

[BoneFlute]

Tak já se obecně domnívám, že ruční psaní unittestů je jen mezistupeň a v budocnosti to nahradí automatika.

Jednotkové testy, tedy alespoň jejich boilerplates, ve Vimu generuji už dávno.

A pak je mažeš?

[BoneFlute]

Pokud je někdo přesvědčen o svém názoru, musí být připraven na protiargumenty oponentů. Prohrává ten, kdo svého oponenta začne ponižovat, protože to je jasným důkazem, že mu došly argumenty.

Když začnu oponenta ponižovat ukazuje to nedostatek mého charakteru. Třeba nedostatek sebeovládání.
A jsou i jiné důvody, proč člověk vzdá diskusi, než jen to, že by došli argumenty.

[Kit]

Pokud je někdo přesvědčen o svém názoru, musí být připraven na protiargumenty oponentů. Prohrává ten, kdo svého oponenta začne ponižovat, protože to je jasným důkazem, že mu došly argumenty.

Když začnu oponenta ponižovat ukazuje to nedostatek mého charakteru. Třeba nedostatek sebeovládání.
A jsou i jiné důvody, proč člověk vzdá diskusi, než jen to, že by došli argumenty.

Když vzdáš diskuzi, tak to ještě nemusí být prohra. Prostě jste se nedobrali konsenzu, to se stává.

[BoneFlute]

Jestli tě chápu dobře - u typů je někdy blbá ta ultimátnost.

A co je to vlastně ta "ultimátnost"? S tím slovem jsem se ještě nesetkal.

Asi takhle. Pomocí testů můžeš otestovat pár vhodných případů, ale nemůžeš otestovat všechny. Nejen, že by si se upsal, ale u negativních to třeba vůbec nejde (https://forum.root.cz/index.php?topic=18804.msg271719#msg271719). Pomocí typů zajistíš naprosto bez výjimky všechny případy.

[Kit]

Tak já se obecně domnívám, že ruční psaní unittestů je jen mezistupeň a v budocnosti to nahradí automatika.

Jednotkové testy, tedy alespoň jejich boilerplates, ve Vimu generuji už dávno.

A pak je mažeš?

Ne. Stávají se součástí dokumentace. Pouze je rozšiřuji a modifikuji, aby lépe testovaly okrajové stavy a různé výjimky.

[Kit]

Asi takhle. Pomocí testů můžeš otestovat pár vhodných případů, ale nemůžeš otestovat všechny. Nejen, že by si se upsal, ale u negativních to třeba vůbec nejde (https://forum.root.cz/index.php?topic=18804.msg271719#msg271719). Pomocí typů zajistíš naprosto bez výjimky všechny případy.

Testy na negativní případy se naopak píší zcela běžně, podle mne dokonce převažují nad pozitivními případy. Pokud metoda má vyhazovat tři výjimky při chybných vstupech, musím otestovat všechny.