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.
A nejaky priklad kde se to dela jinak by nebyl?Ten JSON parser je ale prece sanity check + eval.To by byla ta nejhloupější možná implementace. Protože ten sanity check by v sobě musel obsahovat parser JavaScriptu. Pořád jednodušší je parsovat JSON než JavaScript.
Ten JSON parser je ale prece sanity check + eval.Ale nekdo kdo dela v javasciptu muze mit jiny nazor(na co parsery, dotazovani, knihovny... kdyz je to prece rovnou objekt )Že je to „přece rovnou objekt“ je obrovská bezpečnostní díra a snad už to tak nikdo nepoužívá. I v tom JavaScriptu bylo potřeba napsat na JSON parser – a mimochodem prohlížeče měly z JavaScriptu dostupný XML parser dříve než JSON parser. Že je teď v prohlížečích podpora pro JSON lepší než podpora XML je pravda, ale kvůli tomu nebylo potřeba vytvářet nový formát. Ale je pravda, že zrovna webový svět nenávidí XML opravdu fest a neváhá kvůli tomu dělat některé pitomosti i opakovaně. Takže HTML5 musí mít samozřejmě svou vlastní serializaci, která je hodně podobná XML, ale XML to není. A aby dokázali, že jmenné prostory fakt nepotřebují, vymysleli nejdřív data-atributy, potom vložení SVG a MathML přímo do HTML5 standardu, a nejnověji webové komponenty. Ale ng- je určitě aspoň o 376 % lepší zápis než ng:.
Existuje nějaký zajímavý důvod, proč je ten argument před rovnítkem?
f(x) = x + 1
Kvadratická rovnice je definovaná jako ax^2 + bx +c = 0. Takže když se člověk zeptá "kompilátore, řeší tenhle vzoreček ax^2+bx+c=0, tak se ptá, jestli řeší kvadratickou rovnici jazykem, kterému kompilátor rozumí. Když tam dá jiný (neekvivalentní) vzoreček, tak se na to neptá.No, a když si programátor bude myslet, že kvadratická rovnice je definovaná jako ax^2 + bx = 0, tak se zeptá „kompilátore, řeší tenhle vzoreček ax^2+bx=0?“, tak si bude myslet, že se ptá, jestli řeší kvadratickou rovnici, jazykem, kterému kompilátor rozumí. Programátor pak odevzdá naprogramovanou funkci pro výpočet kvadratické rovnice, kompilátor nebude hlásit žádnou chybu – akorát ta funkce bude ve spoustě případů počítat špatně.
Ne. Bude v te specifikaci podle ktere se testy vygeneruji.To už je jenom nepodstatný detail, čemu přesně říkáte „test“. Já říkám „testy“ celé části kódu, která stojí vedle hlavního kódu a je určená pro testování. Vy asi myslíte nějaký konkrétní testovací framework a „testem“ myslíte například jednu jeho funkci. Na principu to ale nic nemění.
Nekde tady byla otazka na kvadratickou rovnici.Nejvíc bych tomu vytknoul, že si nedovedu představit, že by z takového zápisu byl stroj schopen "pochopit" tu kvadratickou rovnici. Takže nemůže (hypoteticky) "vyvinout" jinou, alternativní implementaci. Zdá se mi to jako algoritmus, který musím "otestovat".
Zkusim tu myslenku v te citaci ukazat na tom.
Podotykam moji myslenku z te citace a ne kompletne problem reseny v tomto vlakne.
BoneFlute se z toho osype, protoze to neni ani zdaleka to o cem mluvil on.
A taky protoze to bude v jazyce velmi podobnem jave :-)
Vlastne jedinny rozdil proti jave je, ze umi presne floating point operace.Kód: [Vybrat]final static RuntimeException up = new IllegalArgumentException("Does not compute");
private static Result getRoots(double a, double b, double c){
double detBody = b*b - 4*a*c;
if(detBody < 0){
throw new IllegalArgumentException("Fuck it! I don't have imaginary friends. " + detBody);
}
double det = Math.sqrt(detBody);
double root1 = (-b + det)/2*a;
double root2 = (-b - det)/2*a;
return new Result(a,b,c,root1,root2);
}
static class Result {
double root1; double root2;
Result (double a, double b, double c, double root1, double root2){
if(root1 + root2 != -(b/a) || root1*root2 != c/a) throw up;
this.root1 = root1;
this.root2 = root2;
}
}
Ne. Bude v te specifikaci podle ktere se testy vygeneruji.To prece delat nechci. Ja chci napsat tu specifikaci a pak na to pustit ten generator testu.Pak tedy nebude ověření správnosti sioučástí typu, ale bude v tom testu.
To prece delat nechci. Ja chci napsat tu specifikaci a pak na to pustit ten generator testu.Ten prispevek je prece o generativnim testovani u dynamicky typovaneho jazyka.Jak zakomponujete ověření správnosti výsledku do konstukce návratového typu, aby se to ověření nedělalo až za běhu, ale už při překladu?
Za behu prece nebudu zapinat "typovou" instrumentaci.
...Huh?
A kdyz zakomponuju overeni spravnosti do konstrukce navratoveho typu zarucim tim ze nepujde vytvorit navratovy typ obsahujici nespravny vysledek.CitaceAno je to v podstate znovuimplementace jinak, ...Asi tak.
final static RuntimeException up = new IllegalArgumentException("Does not compute");
private static Result getRoots(double a, double b, double c){
double detBody = b*b - 4*a*c;
if(detBody < 0){
throw new IllegalArgumentException("Fuck it! I don't have imaginary friends. " + detBody);
}
double det = Math.sqrt(detBody);
double root1 = (-b + det)/2*a;
double root2 = (-b - det)/2*a;
return new Result(a,b,c,root1,root2);
}
static class Result {
double root1; double root2;
Result (double a, double b, double c, double root1, double root2){
if(root1 + root2 != -(b/a) || root1*root2 != c/a) throw up;
this.root1 = root1;
this.root2 = root2;
}
}
Myslim, ze u rady problemu je overeni spravnosti vypoctu trivialni kdezto vypocet samotny je slozity.Jistě existuje řada takových problémů, ale podle mne se to netýká drtivé většiny problémů řešených dnešními programy. Navíc to ověření správnosti zabere nějaký výkon za běhu – lepší je (obvykle) ověřit správnost v době vytváření programu a za běhu se už jen spoléhat na to, že to prostě je správně.
A kdyz zakomponuju overeni spravnosti do konstrukce navratoveho typu zarucim tim ze nepujde vytvorit navratovy typ obsahujici nespravny vysledek.
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.
Nepopisujete nic jiného než obdobu typového systému či jednotkového testu - z popisu nejde pozdnat, čemu je to blíže. Představa, že za vás nějaký jednoduchý systém bezpracně otestuje funkcionalitu, je nesmyslná.
Nechapu. Prece tam sam pisu ze je to neco jako typovy system. A nemam ani zminovanou predstavu.
Ale ten my už máme, teď potřebujeme nějaký lepší (ale snesitelně složitý!), ze kterého si sedneme na pr-del a zavrhneme jednotkové testy jako překonané (na to se přece v této diskusi čeká).
Hromadná kontrola se dá udělat několika způsoby:
- ručně tam ty páry vstup-výstup naboucháte - to nechcete
- použijete data driven testing, to je ale to samé, protože to taky odněkud ta data potřebuje získat - taky k hovnu
- znovuimplementujete výpočet stejně - bude to tentokrát bezchybné?
- znovuimplementujete výpočet jinak - to samé jako výše
Takže s tou o řád vyšší kvalitou protestování bych byl opatrný.
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.
Nepopisujete nic jiného než obdobu typového systému či jednotkového testu - z popisu nejde pozdnat, čemu je to blíže. Představa, že za vás nějaký jednoduchý systém bezpracně otestuje funkcionalitu, je nesmyslná.
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í :-)
(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
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 automatTo 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.Spis mam na mysli to premysleni. To nekdy boli.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.