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
Neil Mitchell wrote: 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.