Automated tests for the libraries?

[Paul Johnson]

Neil Mitchell wrote:
> I don't see much complication in extending my approach. In fact, I
> suspect that my FilePath test extractor is overly complex, since it
> allows:
>
> Windows: property
> Posix: property
> property
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.

In the long run we will also need to handle multi-line properties, the 
QuickCheck forEach combinator, and probably stateful tests of monadic 
actions.

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 []

The letters before the colon are a series of flags, q = QuickCheck, u = 
Unit, f = FastCheck, W = Windows only, P = Posix only, and so on.  Note 
that the "reverse" example is split across lines.

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

Would this make sense?

Paul.