Next steps for "cabal test" feature
batterseapower at hotmail.com
Tue Jan 18 21:59:21 CET 2011
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.
More information about the cabal-devel