unit-testing - 如何在函数式编程中编写好的单元测试

Question

我使用的是函数而不是类，我发现我无法判断它所依赖的另一个函数何时是一个应该单独进行单元测试的依赖项，或者是一个不应该进行的内部实现细节。你怎么知道它是哪一个？

一点上下文:我正在编写一个非常简单的 Lisp 解释器，它有一个 eval()功能。它将有很多责任，实际上太多了，例如以不同于列表的方式评估符号(其他一切都对自己进行评估)。在评估符号时，它有自己复杂的工作流程(环境查找)，而在评估列表时，它就更复杂了，因为列表可以是宏、函数或特殊形式，每个都有自己复杂的工作流程和一套责任。

我不知道我的 eval_symbol()和 eval_list()函数应被视为 eval() 的内部实现细节应该通过 eval() 进行测试自己的单元测试，或者它们自己的真正依赖关系，应该独立于 eval() 进行单元测试的单元测试。

Answer 1

我的建议很简单:“从某个地方开始!”

如果您看到某个 def(或 defun)的名称看起来可能很脆弱，那么您可能想测试它，不是吗？

如果您在试图弄清楚您的客户端代码如何与其他代码单元交互时遇到了一些麻烦，那么您可能希望在某处编写一些测试，让您创建如何正确使用该功能的示例。

如果某些函数似乎对数据值很敏感，那么您可能想要编写一些测试，不仅验证它可以正确处理任何合理的输入，而且还专门练习边界条件和奇数或异常数据输入。

任何看起来容易出错的东西都应该进行测试。

任何看起来不清楚的都应该进行测试。

任何看起来复杂的东西都应该有测试。

任何看起来很重要的东西都应该进行测试。

稍后，您可以将覆盖率提高到 100%。但是您会发现，您可能会从前 20% 的单元测试编码中获得 80% 的实际结果(倒置的“关键少数法则”)。

所以，回顾一下我谦虚的方法的要点，“从某个地方开始!”

关于您问题的最后一部分，我建议您考虑您或后续开发人员将来可能创建的“客户端”函数的任何可能的递归或任何其他可能的重用，这些函数也将调用 eval_symbol() 或 eval_list()。

关于递归，函数式编程风格经常使用它，而且很难做到正确，特别是对于我们这些来自过程或面向对象编程的人来说，递归似乎很少遇到。获得正确递归的最佳方法是通过单元测试精确定位任何递归特性，以确保所有可能的递归用例都得到验证。

关于重用，如果您的函数很可能被 eval() 函数单独使用以外的任何东西调用，那么它们可能应该被视为值得独立单元测试的真正依赖项。

作为最后的提示，“单元”一词在单元测试领域的技术定义为 "the smallest piece of code software that can be tested in isolation."。 .这是一个非常古老的基本定义，可以很快为您澄清您的情况。