【问题标题】:Haskell - Parsec testing with the help of QuickCheckHaskell - 在 QuickCheck 的帮助下进行 Parsec 测试
【发布时间】:2012-10-19 18:45:09
【问题描述】:

我想为 Parsec 解析器编写一个测试。下面是解析器和数据结构的例子:

data Event = Event { keyEvent :: String }
    deriving Show

parseKey :: Parser Event
parseKey = do
             char '<'
             k <- many1 (letter <|> digit <|> oneOf "_")
             char '>'
             return $ Event k

我知道我需要检查parse = parse . pretty . parse 属性。但是我应该如何生成正确不正确测试用例呢?一般来说,我应该如何为给定的BNF 生成测试用例?我知道instance Arbitrary,但没有太多帮助。

如果您为这个简单的解析器提供一个注释良好的生成器示例,我将不胜感激。

【问题讨论】:

  • 对于正确的测试用例,检查id = parse . pretty 是否足够好? (另外,oneOf "_" == char '_'
  • 我认为这就足够了,是的! (而且,第一个版本要奇怪得多)。
  • @dbaupp:我考虑过这个,不,考虑一个简单的例子,当解析器中有spaces或其他可跳过的字符,那么产生的结果会有所不同。额外的parse 会有所帮助。

标签: haskell parsec quickcheck


【解决方案1】:

测试解析器并不完全是微不足道的。 (取决于事物的复杂性,与所有测试一样。)

您可以做的一件事是编写一个 Arbitrary 实例,该实例构造所有有效的表达式(或您要解析的任何表达式),然后检查您是否漂亮地打印该内容,然后解析结果字符串,您将完全恢复您开始时的状态。

这有几个问题:

  • 如果答案是错误的,那是什么问题?解析器还是打印机?

  • 如果您要解析的东西足够复杂,以至于有可选的括号和其他东西,您需要检查它是否可以使用和不使用可选的括号。通常,您漂亮的打印机只会以一种或另一种方式完成。

  • 这不会检查垃圾输入是否真的被拒绝(并且不会被解析为奇怪的东西)。例如,我写了很多 Parsec 解析器,如果语法错误发生在输入的 end 处,它们会默默地忽略它。

一般来说,我所知道的唯一真正彻底测试解析器的方法是手动编写大量的手动测试。 (并且每次您发现解析错误的内容时,为其添加另一个测试用例。)例如,这基本上就是 GHC 对他们的测试套件所做的。

当然,这取决于您的解析器有多复杂,以及您想要多少保证……如果您只是解析 JSON,您可能可以相当容易地对其进行测试。如果你正在解析 Markdown 之类的东西......我的上帝怜悯你的灵魂!

【讨论】:

  • 我正在编写XCompose 的解析器,如果有兴趣here 是来源。那么,为此创建 QuickCheck 是否有意义?还是手写测试会更好?第二种情况可以推荐什么库?
  • 您当然可以两者做这些事情。使用 QuickCheck 验证从 AST 到字符串到 AST 的往返是否有效,并编写一些手动测试来检查边缘情况。它看起来像一个相当小的语法,所以测试起来应该不会太难......
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多