<thelema>
possibly because the ocaml community hasn't embraced unit tests, but more likely due to deficiencies in camlp4/ocaml
<mrvn>
ocaml code just works so damn well we don't need testing. It either works or doesn't compile. :)
<thelema>
mrvn: I wish
<mrvn>
yezariaely: camlp4 can do write you of_string and to_string functions for your type. some people have written the modules for it somewhere.
<flux>
mrvn, ocaml developers just get smarter about writing better bugs
<flux>
it's an arms race
mnabil has quit [Read error: Connection timed out]
<flux>
I wonder what kind of bugs Coq people write..
<kmicinski>
I think a lot of bugs come from people trying to either rape the type system or do things they don't understand
mnabil has joined #ocaml
<kmicinski>
I'd wager to say that's where *most* of the bugs come from
<mrvn>
kmicinski: (Obj.magic 0) ()
<gildor>
what Obj.magic is dangerous ?
<thelema>
many many bugs come from Obj.magic or C bindings
<gildor>
;-)
<mrvn>
Usualy such bugs are segfaults.
<thelema>
the best kind
<mrvn>
And all segfaults are such bugs I would say.
<kmicinski>
I've never used the FFI stuff
<mrvn>
Obj, C and marshaling actually.
<mrvn>
But sometimes you write algorithm bugs where you just didn't thing straight or forgot some special case or something.
<mrvn>
e.g. your sorted tree suddenly becomes unsorted and then you have fun.
<kmicinski>
that covers the last half of my statement
<thelema>
yes, it's still easy to break things without the type system catching. I'm not saying that unit tests are always the best way to deal with this, but they can be a handy tool, and ocaml testing is *ugly*
<mrvn>
I find unit tests rather useless. They only test the things you thought about and those I tend to get right. But maybe that changes after a year or two and some major revisions.
<thelema>
mrvn: I'd argue they have a place, and that lots of dumb bugs can be caught by them.
<mrvn>
And they tend to make people test code to see if it is right instead of checking it properly.
<mrvn>
thelema: sure. if you find them usefull then use them. Just my personal opinion for the little projects I've done so far.
<kmicinski>
I think unit tests are for large companies / c++ codebases :-)
<mrvn>
the larger the project the more needed they are I would say.
<edwin>
I think you need at least some tests that basic functionality is still working
<edwin>
working in the sense of outputting correct results
<edwin>
not "it segfaults, doesn't segfaults"
<mrvn>
I guess if you have multiple people working on something then one can write the module, the other the unit tests and vice versa.
* edwin
should write more tests too
<kmicinski>
mrvn, yes, that's how it worked when I interned at huge company
<mrvn>
edwin: When I work on a module I often write a test.ml to test the functions. But I've never formalized that into unit tests and kept them.
tmaeda has quit [Ping timeout: 255 seconds]
tmaeda has joined #ocaml
ftrvxmtrx has quit [Quit: Leaving]
smerz has joined #ocaml
opla2 has quit [Ping timeout: 264 seconds]
Edward_ has quit [Ping timeout: 276 seconds]
kmicinski has quit [Ping timeout: 260 seconds]
ftrvxmtrx has joined #ocaml
jm_ocaml has quit [Remote host closed the connection]
Edward_ has joined #ocaml
oriba has joined #ocaml
edwin has quit [Remote host closed the connection]
mnabil_ has joined #ocaml
zhengli has quit [Quit: Leaving.]
mfp has quit [Ping timeout: 255 seconds]
mnabil_ has quit [Remote host closed the connection]