7

我已经问了一个相关的问题，但我没有得到满意的答案。所以，也许我应该换个方式问它。

像 Perl 或 Ruby 甚至 Linux 内核这样的大型 C 项目如何处理单元测试？甚至在任何功能语言中？

我熟悉用于 OOP 中的测试的依赖注入和抽象工厂，但我没有看到非 OOP 中的可扩展和可管理的等效性。例如，在 C 或 Haskell 中，函数层之上会有层，较高层隐式调用较低层。我如何找到接缝来测试一个代码单元而不是它的所有依赖项？

避免所有接缝需要的一种方法是将调用依赖图的深度保持在非常低的水平。可以这么说，水平编码而不是垂直编码。在“叶子”函数中保留尽可能多的应用程序逻辑；并确保“节点”函数除了将数据连接到其他节点/叶函数之外没有任何工作。然后，只测试“叶子”功能；将“节点”功能留给集成测试。这种方法有效吗？

今天最大的软件仍然是用过程语言编写的。必须采用一些有效的方法。具有良好单元测试的程序语言大型软件经验的人可以发表评论吗？

4

2 回答 2

5

函数式语言具有其他用于模块化的构造（对象除外），例如 ML 仿函数。“依赖注入”基本上是“抽象事物”的美名，并且在函数式语言中使用了很长时间。

在所有范例中，测试都应遵循规范边界。如果你知道一段给定的代码（函数、方法、对象……）应该做什么，你应该对照这个规范进行测试。对于叶函数，这将是单元测试，对于“节点”函数，如果您愿意，这可以被视为“集成测试”，但实际上是相同的活动。

我想你会发现同样的方法论本质上也适用于函数式编程，而且结果本质上是一样的；特别是，（重新）设计易于测试的代码也提高了它的模块化和可维护性。

于 2011-04-06T14:53:50.180 回答
1

设计易于测试的代码也提高了它的模块化和可维护性。

不对。设计易于测试的代码可以提高编写测试代码的难度。

功能模块的自然划分通常不是最方便单元测试的。这就是为什么现在有这么多 Java 代码被分解成很小的、分散的片段，而每个片段本身大多没有用处。

于 2011-08-08T21:31:55.803 回答