Next steps for "cabal test" feature

[Thomas Tuegel]

Here, at last, is the patch I promised. It would not have taken this
long, but I wanted to get the module documentation correct. So, this
patch not only has a new interface, but an example implementation (in
the module docs) of the detailed test interface for QuickCheck >= 2.3.

The patch does what we talked about: a single "Testable" class and
options with GetOpt (the one bundled with Cabal). The interface in
this patch assumes that all tests are safe; supporting safe and unsafe
tests would be a simple matter of adding another constructor to the
"Test" type. The new interface has the advantage of being
substantially simpler, i.e., shorter, and without all the exceptions
junk.

I did not bump the version number for the test type; it's still
"detailed-0.9" because I wasn't sure if we want to bump it or what we
want to bump it to. (Are we ready to bump to "detailed-1.0"? )

On Tue, Jan 18, 2011 at 2:59 PM, Max Bolingbroke
<batterseapower at hotmail.com> wrote:
> On 11 January 2011 18:09, Thomas Tuegel <ttuegel at gmail.com> wrote:
>> One thing to do would be to change the interface so there is only one
>> "Testable" class, allow tests in it to run in IO,
>
> I would be happy with this.
>
>> and provide some
>> kind of combinator for denoting safe/unsafe tests.
>
> That might be a possible extension. I am of the opinion that "unsafe"
> tests (i.e. those which cannot be run in parallel with other tests)
> are both rare and undesirable from a design perspective, and so we
> should not provide explicit support for them.
>
>> One other thing we've been discussing is what to do about TestOptions.
>> The fallout of this discussion is essentially that everything
>> TestOptions is trying to do, GetOpt does better.
>> ...
>> have a method such as "options :: [OptDescr (t -> t)]" in class
>> Testable. Option 3 is to delegate option parsing to the test provider.
>> I prefer option 2: compared to option 3, it enforces standardization
>> more rigidly and takes some of the work off test provider authors.
>
> Option 2 seems like a reasonable choice. GetOpt isn't perfect (I like
> cmdargs) but it does have the considerable advantage of being a
> de-facto standard and is in the base package. I think your idea to use
> [OptDescr (t -> t)] is particularly elegant!
>
> I look forward to seeing your patch :-). Let me (and the list) know if
> any more issues come up.
>
> Cheers,
> Max
>

-- 
Thomas Tuegel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cabal-new-detailed-tests.dpatch
Type: application/octet-stream
Size: 51612 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20110217/9faa814e/attachment-0001.obj>