是否应该对复杂的正则表达式进行单元测试？

我应该在应用程序中为复杂的正则表达式编写单元测试吗？

• 一方面：它们易于测试，因为输入和输出格式通常很简单且定义明确，而且它们往往变得如此复杂，因此对它们的测试特别有价值。
• 另一方面：它们本身很少是某个单元界面的一部分。最好只测试接口，然后以隐式测试正则表达式的方式进行操作。

编辑：

我同意布朗博士的意见，他在评论中指出这是内部组件单元测试的特例。

但是正则表达式作为内部组件具有一些特殊特征：

1. 没有真正的单独模块，单行正则表达式可能非常复杂。
2. 正则表达式将输入映射到输出而没有任何副作用，因此真正易于单独测试。

除了测试教条主义，真正的问题是它是否为单元测试复杂的正则表达式提供价值。很显然，如果正则表达式足够复杂，它确实可以提供价值（不管正则表达式是否是公共接口的一部分），因为正则表达式允许您查找和重现错误并防止回归。

正则表达式可以是一个功能强大的工具，但即使对复杂的正则表达式进行很小的更改，它也不是您可以信赖的工具，它仍然可以正常工作。

因此，创建大量测试以记录应涵盖的案例。并创建许多测试，以记录如果失败用于验证的情况。

每当需要更改正则表达式时，都将新案例添加为测试，修改正则表达式并希望获得最佳效果。

如果我所在的组织通常不使用单元测试，我仍然会编写一个测试程序来测试我们要使用的任何正则表达式。如果需要的话，我什至会自己动手做，我的头发不再需要褪色。

正则表达式与应用程序的其余部分一起是代码。您应该测试代码总体上是否符合您的期望。这有几个目的：

• 测试是可运行的文档。它清楚地演示了您需要代码执行的操作。如果经过测试，那很重要。
• 将来的维护者可以确定，如果他们对其进行修改，则测试将确保行为不变。

由于将其他语言的代码嵌入到其他代码中还需要克服一个额外的障碍，因此您很可能应该特别注意这一点，以便维护。

简而言之，您应该测试您的应用程序。无论您是使用自动运行的正则表达式来测试正则表达式，还是作为一个更大的黑匣子的一部分来进行测试，还是仅是手工摆弄它，都是您要确保它正常工作的第二要务。

单元测试的主要优点是可以节省时间。他们使您可以现在或将来的任意时间对事物进行多次测试。如果有任何理由相信您的正则表达式将在任何时候进行重构，调整，获得更多约束等，那么是的，您可能需要对其进行一些回归测试，或者当您进行更改时，您必须经过一个小时的思考，对所有极端情况进行了思考，这样您才不会遇到麻烦。那样，或者您学会了忍受着自己的代码的恐惧，并且永远不要更改它。

另一方面：它们本身很少是某个单元界面的一部分。最好只测试接口，然后以隐式测试正则表达式的方式进行操作。

我认为您可以自己回答。一个单元中的正则表达式很可能是实现细节。

用于测试SQL的内容可能也适用于正则表达式。当您更改一条SQL时，您可能需要手动通过某个SQL客户端运行它，以查看它是否产生了预期的效果。当我更改正则表达式时，我也会使用带有某些示例输入的正则表达式工具来查看其是否符合我的预期。

我发现有用的是在正则表达式附近添加了注释，并带有应匹配的文本示例。

如果需要询问，答案是肯定的。

假设出现了一些FNG，并认为他可以“改善”您的正则表达式。现在，他是一名FNG，因此自然是个白痴。恰恰是那种在任何情况下都不应该触摸您的宝贵代码的人！但是也许他和PHB有关，所以您无能为力。

除非您知道PHB会拖延您的踢踢和尖叫，否则一切都会变坏时“也许会给这个家伙一些有关您如何使此混乱的指示”。因此，您记下在构建漂亮的表达力杰作时仔细考虑的所有案例。

既然已经将它们全部写下来，那么您拥有一套测试用例的方式就占了三分之二，因为-让我们面对现实-一旦构建了框架，正则表达式测试用例就非常容易运行。

因此，现在您有了一组边缘条件，替代方法和预期结果。就像所有这些敏捷的博客文章中所承诺的那样，突然之间，测试用例就是文档。您只是向FNG指出，如果他的“改进”没有通过现有的测试用例，那就不是很大的改进，不是吗？他提出的新测试用例在哪里，这些原始用例证明了原始代码的某些问题，由于该代码有效，因此他不需要进行修改！！！