Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Testing parsers is not entirely trivial. (Depending on the complexity of the thing, as with all testing.)</p> <p>One thing you can do is write an <code>Arbitrary</code> instance which constructs all valid expressions (or whatever it is you're trying to parse), and then check that if you pretty-print the thing and then parse the resulting string, you get back exactly what you started with.</p> <p>There are a couple of problems with that:</p> <ul> <li><p>If the answer is wrong, what's broken? The parser or the printer?</p></li> <li><p>If the thing you're parsing is complicated enough to have optional brackets and things, you need to check it works both with and without the optional brackets. Your pretty printer will only do it one way or the other, usually.</p></li> <li><p>This doesn't check that garbage input really does get rejected (and not parsed as something strange). E.g., I've written plenty of Parsec parsers which will silently ignore a syntax error if it occurs at the <em>end</em> of the input.</p></li> </ul> <p>In general, the only really <em>thorough</em> way I know of testing a parser is to just write lots and lots of manual tests by hand. (And every time you find something that parses wrong, add another test case for it.) This is essentially what GHC does with their test suit, for example.</p> <p>Of course, it depends how complex your parser is, and how much assurance you want... If you're just parsing JSON, you can probably test it fairly easily. If you're parsing something like Markdown... my God have mercy on your soul!</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload