Automated tests for the libraries?

[Neil Mitchell]

Hi

> I actually think that something like this should be preserved.  I can
> imagine several reasons for having flags of this kind.
> Platform-specific flags are an obvious one.  Another would be to
> distinguish QuickCheck, HUnit and FastCheck tests, as well as tests that
> take no arguments.  Currently Neil treats these as QuickCheck tests, but
> this (unless I'm mistaken) will result in each one being called 100
> times, which shouldn't be necessary.

Nope, I treat them as properties and assert them once. The algorithm I
use is that things which are single letters are free variables, and
single letter followed by 's' - if a property has no free variables
its an assertion and only gets executed once.

> So I suggest that we look for lines of the form
>
> -- > q: reverse (xs ++ ys) ==
> -- >       (reverse ys ++ reverse xs)
> -- > u: reverse "foobar" == "raboof"
> -- > u: null $ reverse []

I would have thought:

> -- > forall xs ys . reverse (xs ++ ys) == (reverse ys ++ reverse xs)
> -- > reverse "foobar" == "raboof"
> -- > null $ reverse []

I suspect the quantification will be needed explicitly so you can tell
between reverse the free variable and reverse the function.

> Incidentally, how does the test extractor handle arguments?  Does it
> parse the code for variables?  If so then could we have a line to
> declare argument types for properties where they can't be inferred?
> Something like:
>
> -- > t: xs, ys :: [Int]
> -- > t: str :: String

I have a scheme where some set of letters refers to file names, and
some to other stuff. I also wrap things as well, to get a different
quickcheck generator - i.e. newtype CheckFilePath = CheckFilePath
FilePath, then unwrap it before doing the actual call.

There are lots of design decisions - the best thing would be to set up
a wiki page as the theoretical documentation of the tool, then once
the manual is stable you can write the tool.

Feel free to take any or none of my tool as the starting point.

Thanks

Neil