unit-testing - 解析器的单元测试

Question

如何为以下场景编写单元测试？

要测试的程序是一个解析器，它可以识别输入中的不同结构。您可以将其视为解析标记语言。

一个核心问题是在某些模式匹配时识别文本中的结构。实际上，这些不会是正则表达式，但对于这个问题，将它们视为正则表达式应该没问题。

问题

假设我想识别房间号并有一个模式 p 来匹配输入中与一组模式中的任何其他模式 p2 不匹配的部分(例如，我的虚构输入文档的页眉和页 footer 分) .

我可以想象编写单元测试，期望为给定的输入找到多个房间号。然而，提出好的测试，特别是边界案例，在这里确实是有问题的。

测试:

有趣的测试用例应该以某种方式解释不同的模式组合。特别是确定某些文本是否与房间号的模式相匹配，这很简单，而且更像是一个(当然，仍然很重要)很好的单元测试。我可以区分几种测试:

1.:
"007" - expect: false
"01-001" - expect: true
"R02-33b" - expect: true
"01-001andsometext" - expect: false
"01-001 andsometext" - expect: true
"02-33X" - expect: false
"" - expect: false

2.:
"We meet in R01-001. Please invite agent 007." -- expect 1 matching rooms
"Excercise groups take place in 02-23b and 02-33c." --- expect 2 matches
... 

3.:
Integration test style. 
Long input with room numbers in the texts and in header/footer 
where I only want to recognize n rooms:
"... 150+ character string ..." - expect exactly 7 matches, 
                                  check if the right ones are matched

虽然第一个是一个非常好的单元测试，它只测试了我程序中非常固定的部分，但也很容易忘记困难的情况。看第二个例子，我可能会对自己说:“伙计，我真的应该包含一个测试用例，其中房间号后面跟着句号、问号等。”

然而，第二个例子并没有好多少。特别是我仍然会错过许多“边界情况”，因为解析器有太多(其他标点符号、Unicode 等)。

但除此之外，我真正想要的不仅是检测某种格式的房间号，还要忽略那些处于“坏”部分的房间号。测试“真实/典型”的解析似乎是糟糕的单元测试实践:几乎不可读，预期结果很容易改变我的程序的其他部分(设置的“坏”模式)等等。

到目前为止我的结论

不知何故，我认为我会想要编写典型的单元测试 - 就像我的示例 1 中一样。但是，我认为我需要许多不同类型的输入，并且仍然会错过更多边界情况(例如 unicode 标点符号)等等)比我通常对数字、树、图形等工作的其他函数所做的更多。所以我真的希望从那些在处理字符串输入方面有更多经验的人那里得到一些建议。

Answer 1

根据我的观点和经验，最好的方法是检查单元测试创​​建的代码覆盖率。根据结果​​，您可以看到代码的哪些区域没有经过测试，这会提示您必须在哪些区域编写测试。在这种情况下，您总是会遇到可能会错过一些边缘情况的问题。