Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Caml-list] [ANN] Kaputt 1.0 alpha

26 views
Skip to first unread message

bar...@x9c.fr

unread,
Nov 23, 2008, 3:57:47 PM11/23/08
to caml...@inria.fr
This post announces the 1.0 alpha version of Kaputt.
Kaputt is a testing tool for the Objective Caml language.
Home page: http://kaputt.x9c.fr

Features:
- assertion-based tests (inspired by the xUnit tools):
the developer writes assertions by explicitly stating
input and waited output values for the tested function;
- specification-based tests (inspired by the QuickCheck tool):
the developer writes (using combinators) a specification
of the tested function and asks the library to randomly generate
tests cases.

Dependencies:
- Objective Caml 3.10.2

Planned features:
- more combinators and predicates (e.g. over Map, Set, etc.);
- generalization of generator to accept other sources (e.g. streams).


This is clearly alpha work, so any suggestion/criticism will be
welcome in order to enhance/correct it.

Xavier Clerc

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Stefano Zacchiroli

unread,
Nov 23, 2008, 4:31:09 PM11/23/08
to caml...@inria.fr
On Sun, Nov 23, 2008 at 09:57:37PM +0100, bar...@x9c.fr wrote:
> This is clearly alpha work, so any suggestion/criticism will be
> welcome in order to enhance/correct it.

Hi Xavier, thanks for this.

You are probably aware of oUnit [1] which, AFAIK, was the only testing
library available for OCaml thus far. Hence I guess you developed
Kaputt to achieve something which was not possible with oUnit or to
achieve it somehow differently.

Can you please comment over the differences between Kaputt and oUnit?

I'm quite sure it would be interesting for a lot of us.

TIA,
Cheers.

[1] http://www.xs4all.nl/~mmzeeman/ocaml/ounit-doc/OUnit.html

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'č ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu ą tous ceux que j'aime

fo...@x9c.fr

unread,
Nov 23, 2008, 6:10:48 PM11/23/08
to caml...@inria.fr
Selon Stefano Zacchiroli <za...@upsilon.cc>:

> On Sun, Nov 23, 2008 at 09:57:37PM +0100, bar...@x9c.fr wrote:
> > This is clearly alpha work, so any suggestion/criticism will be
> > welcome in order to enhance/correct it.
>
> Hi Xavier, thanks for this.
>
> You are probably aware of oUnit [1] which, AFAIK, was the only testing
> library available for OCaml thus far. Hence I guess you developed
> Kaputt to achieve something which was not possible with oUnit or to
> achieve it somehow differently.
>
> Can you please comment over the differences between Kaputt and oUnit?

I was indeed aware of oUnit when I started working on Kaputt.
The initial intent was to provide OCaml with something along
the lines of the QuickCheck library developed for Haskell
(http://www.cs.chalmers.se/~rjmh/QuickCheck/). Clones of QuickCheck
exist for various languages (caml...@inria.fr) but not for OCaml,
even if a QuickCheck equivalent is provided by the Reins library
(http://ocaml-reins.sourceforge.net/).

Put shortly, the idea of QuickCheck is to encode the specification
of a function using predicates and to ask the framework to generate
random test cases to check that the function adheres to its specification.

After designing this part of the library, I realized that it would
be quite annoying (at least for me, the very first user) to have
two libraries to code my tests. That's why I decided to add to Kaputt
the functionalities found in oUnit.

In summary: Kaptt = oUnit + {QuickCheck part of Reins}.
People may get angry at such effort duplication, and I would understand
it. My point is to put forward a unique library specialized in testing.


Xavier

fo...@x9c.fr

unread,
Nov 23, 2008, 6:19:16 PM11/23/08
to caml...@inria.fr
Selon fo...@x9c.fr:

> Selon Stefano Zacchiroli <za...@upsilon.cc>:
>
> > On Sun, Nov 23, 2008 at 09:57:37PM +0100, bar...@x9c.fr wrote:
>
> Clones of QuickCheck exist for various languages
> (caml...@inria.fr) but not for OCaml

Hum, copy/paste mistake, the URL for QuickCheck clones is:
http://en.wikipedia.org/wiki/Quickcheck

Yoann Padioleau

unread,
Nov 24, 2008, 11:54:49 AM11/24/08
to fo...@x9c.fr, caml...@inria.fr
fo...@x9c.fr writes:

Hi Xavier,

> Selon Stefano Zacchiroli <za...@upsilon.cc>:
>
>> On Sun, Nov 23, 2008 at 09:57:37PM +0100, bar...@x9c.fr wrote:
>> > This is clearly alpha work, so any suggestion/criticism will be
>> > welcome in order to enhance/correct it.
>>
>> Hi Xavier, thanks for this.
>>
>> You are probably aware of oUnit [1] which, AFAIK, was the only testing
>> library available for OCaml thus far. Hence I guess you developed
>> Kaputt to achieve something which was not possible with oUnit or to
>> achieve it somehow differently.
>>
>> Can you please comment over the differences between Kaputt and oUnit?
>
> I was indeed aware of oUnit when I started working on Kaputt.
> The initial intent was to provide OCaml with something along
> the lines of the QuickCheck library developed for Haskell
> (http://www.cs.chalmers.se/~rjmh/QuickCheck/). Clones of QuickCheck
> exist for various languages (caml...@inria.fr) but not for OCaml,

Actually I posted a few years ago a small module imitating parts of quicheck:

http://aryx.kicks-ass.org/~pad/ocaml/quickcheck.ml

Apparently they even now use my ugly file in the Janet Street Core Library.


> even if a QuickCheck equivalent is provided by the Reins library
> (http://ocaml-reins.sourceforge.net/).

I didn't find much in this ocaml reins library ... and it
looks quite heavy in functors ...


Your library looks very good, very clean. I just noticed you missed
the 'pair' and 'tuple' random generators.


One criticism is that like many other libraries, such as oUnit,
ocamlcalendar, they seem a little bit heavyweight. You got hundreds
of functions, 5 modules ...

Sylvain Le Gall

unread,
Nov 24, 2008, 12:08:48 PM11/24/08
to caml...@inria.fr
On 24-11-2008, Yoann Padioleau <pad...@wanadoo.fr> wrote:

> fo...@x9c.fr writes:
>
> One criticism is that like many other libraries, such as oUnit,
> ocamlcalendar, they seem a little bit heavyweight. You got hundreds
> of functions, 5 modules ...
>

I always found oUnit quite lightweight compared to other. It is part of
those library small enough to understand quickly. So I don't agree on
the fact that "oUnit" is heavyweight.

Regards,
Sylvain Le Gall

fo...@x9c.fr

unread,
Nov 24, 2008, 2:13:38 PM11/24/08
to caml...@inria.fr

Le 24 nov. 08 à 17:52, Yoann Padioleau a écrit :

> fo...@x9c.fr writes:
>
> Hi Xavier,
>
>> Selon Stefano Zacchiroli <za...@upsilon.cc>:
>>

>>> (...)


>>
>> I was indeed aware of oUnit when I started working on Kaputt.
>> The initial intent was to provide OCaml with something along
>> the lines of the QuickCheck library developed for Haskell
>> (http://www.cs.chalmers.se/~rjmh/QuickCheck/). Clones of QuickCheck
>> exist for various languages (caml...@inria.fr) but not for OCaml,
>
> Actually I posted a few years ago a small module imitating parts of
> quicheck:
>
> http://aryx.kicks-ass.org/~pad/ocaml/quickcheck.ml

Sorry, I failed to remember this.


> Apparently they even now use my ugly file in the Janet Street Core
> Library.
>
>
>> even if a QuickCheck equivalent is provided by the Reins library
>> (http://ocaml-reins.sourceforge.net/).
>
> I didn't find much in this ocaml reins library ... and it
> looks quite heavy in functors ...

Yes, I indeed wanted to rely upon functions/combinators instead.
It seems lighter this way.


> Your library looks very good, very clean. I just noticed you missed
> the 'pair' and 'tuple' random generators.

Well, maybe their names are not intuitive but Generator.zip{1..5}
allows to combine n generators into a generator returning tuples
of order n (zip1 being the identity function).


> One criticism is that like many other libraries, such as oUnit,
> ocamlcalendar, they seem a little bit heavyweight. You got hundreds
> of functions, 5 modules ...

That's true but it seems hard to have a combinator-based library with
few functions/combinators. With too few combinators, you leave too
much work to the developer (including a lot a boilerplate code).
With too many combinators, you request the developer to take more
time in order to use the library. I find it hard to calibrate the size
of
the library.

Maybe things could be done in a lighter way by using objects ?

Christophe Raffalli

unread,
Nov 24, 2008, 4:50:12 PM11/24/08
to fo...@x9c.fr, caml...@inria.fr
fo...@x9c.fr a écrit :
Or a camlp4 extension to build the intended function(s) by induction on
the type definition.
you could include that as part of deriving
(http://code.google.com/p/deriving/)

Hope this helps,
Christophe


>
>
> Xavier
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>


--
Christophe Raffalli
Universite de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tel: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christoph...@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature. The public key is
stored on www.keyserver.net
---------------------------------------------

Christophe_Raffalli.vcf
signature.asc

Yoann Padioleau

unread,
Nov 24, 2008, 5:07:27 PM11/24/08
to Christophe Raffalli, caml...@inria.fr
Christophe Raffalli <Christoph...@univ-savoie.fr> writes:

>>> Your library looks very good, very clean. I just noticed you missed
>>> the 'pair' and 'tuple' random generators.
>>
>> Well, maybe their names are not intuitive but Generator.zip{1..5}
>> allows to combine n generators into a generator returning tuples
>> of order n (zip1 being the identity function).
>>
>>
>>> One criticism is that like many other libraries, such as oUnit,
>>> ocamlcalendar, they seem a little bit heavyweight. You got hundreds
>>> of functions, 5 modules ...
>>
>> That's true but it seems hard to have a combinator-based library with
>> few functions/combinators. With too few combinators, you leave too
>> much work to the developer (including a lot a boilerplate code).
>> With too many combinators, you request the developer to take more
>> time in order to use the library. I find it hard to calibrate the size of
>> the library.
>>
>> Maybe things could be done in a lighter way by using objects ?

> Or a camlp4 extension to build the intended function(s) by induction on
> the type definition.
> you could include that as part of deriving
> (http://code.google.com/p/deriving/)

Which would make it even more heavyweight by forcing now the client
to use campl4, to download your deriving library, to understand
this deriving stuff, to infer the names of the functions
now that they will be hidden/internally-generated by campl4 ...

Look at the ocaml standard library, why do you like it ?
Because it's simple. A few types, a "kernel" of essential functions,
not too much functors (well in fact I would prefer even less functors
such as a simpler Map and Set like the Hashtbl module). KISS.

fo...@x9c.fr

unread,
Nov 24, 2008, 5:52:18 PM11/24/08
to caml...@inria.fr

Le 24 nov. 08 à 22:49, Christophe Raffalli a écrit :
>>
>> (...)

>>
>> Maybe things could be done in a lighter way by using objects ?
> Or a camlp4 extension to build the intended function(s) by induction
> on
> the type definition.
> you could include that as part of deriving
> (http://code.google.com/p/deriving/)


Good idea.
I would regard a deriving-based "class" for generation
of test cases as a very useful enhancement.

However, I do not know the policy of the "deriving"
developers. Would they accept a "class" relying on
a library besides the standard library ?

Jeremy Yallop

unread,
Nov 25, 2008, 4:51:51 AM11/25/08
to fo...@x9c.fr, caml...@inria.fr
fo...@x9c.fr wrote:
> Le 24 nov. 08 à 22:49, Christophe Raffalli a écrit :
>> Or a camlp4 extension to build the intended function(s) by induction on
>> the type definition.
>> you could include that as part of deriving
>> (http://code.google.com/p/deriving/)
>
> Good idea.
> I would regard a deriving-based "class" for generation
> of test cases as a very useful enhancement.
>
> However, I do not know the policy of the "deriving"
> developers. Would they accept a "class" relying on
> a library besides the standard library ?

Yes: such contributions would be welcome. It wouldn't be necessary for
users of "deriving" to link in your library unless they were actually
using it.

It would also be possible to distribute your "class" separately from
deriving. The design of deriving (based on the underlying camlp4
facility for loading object files dynamically) allows classes (i.e. code
generators) to be loaded at runtime, so there's no need to modify the
whole program just to add a new class.

Jeremy.

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

0 new messages