Next steps for "cabal test" feature

[Richard G.]

This is great news!

I'll try to add HUnit support this weekend.

Richard

On 2/17/11 8:22 AM, Thomas Tuegel wrote:
> 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
>>
>
>
>
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel