我问了一个相关的question，但我得不到满意的答复。所以，也许我应该以不同的方式问它。
大型C项目（如Perl或Ruby，甚至Linux内核）如何处理单元测试？甚至用任何功能语言？
我对OOP中的测试熟悉Dependency Injection和Abstract Factory，但我没有在非OOP中看到可扩展且可管理的等价。例如，在C或Haskell中，会有多层函数层，而较高层则隐含地调用较低层。如何找到仅仅测试代码单元而不是所有依赖项的接缝？
避免一起使用接缝的一种方法是将调用依赖图的深度保持在非常低的水平。可以说是水平编码而不是垂直编码。在“叶子”功能中尽可能多地保留应用程序逻辑;并确保除了将数据传递给其他节点/叶子函数之外，“节点”函数不起作用。然后，只测试“叶子”功能;将“节点”功能留给集成测试。这种方法有效吗？
今天最大的软件仍然是用过程语言编写的。必须采用一些有效的方法。那些具有大规模软件经验的程序语言能否有良好的单元测试评论？
答案 0 :(得分：5)
函数式语言具有模块化的其他结构（而不是对象），例如ML仿函数。 “依赖注入”基本上是“抽象事物”的美化名称，并且已经在函数式语言中使用了很长时间。
在所有范例中，测试都应遵循规范边界。如果你知道给定的一段代码（函数，方法，对象......）应该做什么，你应该测试这个规范。对于叶子函数，这将是单元测试，对于“节点”函数，如果你愿意，这可以被认为是“集成测试”，但它实际上是相同的活动。
我认为您会发现相同的方法基本上适用于函数式编程，结果基本相同;特别是，（重新）设计易于测试的代码也提高了其模块性和可维护性。
答案 1 :(得分：1)
设计易于测试的代码也可以提高其模块性和可维护性。
不正确。设计易于测试的代码可以提高编写测试代码的难易程度。
功能模块的自然划分通常不是单元测试最方便的。这就是为什么如今如此多的Java代码被分解成微小的，分散的部分，每个部分本身几乎没用。