See patch318 for context.
Having some round trip quickchecks would be great. From this effort to
date (I had a few failed attempts at this refactor), I think these are some
of the properties that ideal tests would check:
1. Basic sanity checks, can things be parsed in the ideal/typical cases?
2. How do high level parsers compose? Since the parser monad is stateful
on the input, it would be nice to check that the parsers do not consume
more/less at the end of their parse than they were meant to.
3. Sequences are dealt with correctly: empty sequences, many elements,
good elements followed by partial elements, etc.
4. linesStartingWith and linesStartingWithEndingWith are hard to get
right and performance critical.
5. Dealing with almost correct input. Like fuzz testing.
In my experience, #2 is important but hard to define. The purpose of #5 is
to see if we accept things that should be rejected. I'm not aware of
anyone using fuzz testing with Haskell, but darcs would be a good candidate
for that type of testing. The more tests we have to cover #4, the more
aggressively we can refactor those for performance reasons.
I forgot to mention. I'm assuming that many of the tests we could write
would be round trip tests: Randomly generate patchinfos/patches, show
them, parse them back, and compare that they are still equal.
Checking the left over input after the parse is also of interest, as per