4 ms·

> It's far easier to handwrite parsers. It's also far easier to make buggy handwritten parsers. I don't have much experience, but in the project that I've seen

• rhdunn 4y ago
  I tend to write lots of tests at each level -- lexer, parser, AST, etc. -- to cover the different BNF grammar statements. I've done this with an XQuery and XPath parser I wrote for IntelliJ. You can cover the different lexical variations in the lexical tests, and ensure that the lexer is reporting the correct things in the lexer tests. For these, I generally ensure I cover each token in a given BNF grammar statement, even if that means repeating checks for a given keyword, as it keeps the tests self-contained and easier to verify. You can cover the different parser/grammar variations (different branches/paths in the BNF, missing tokens for error reporting and recovery, etc.) in the parser tests. These can make use of serializing the tree to a file, so your input is an example program and the output is the parsed AST tree. The AST tests can then test the actual data model your AST provides, such as access to the value of a literal, or information about a type. Higher-level tests such as constant folding can then be done using the AST API, or things like serializing the AST to a textual representation.