kir*_*kun 7 unit-testing procedural-programming functional-programming
我问了一个相关的问题,但我得不到满意的答复.所以,也许我应该以不同的方式问它.
大型C项目(如Perl或Ruby甚至Linux内核)如何处理单元测试？甚至在任何功能语言中？
我熟悉依赖注入和抽象工厂的OOP测试,但我没有看到非OOP中的可扩展和可管理的等价.例如,在C或Haskell中,会有多层函数层,而较高层则隐含地调用较低层.如何找到仅仅测试代码单元而不是所有依赖项的接缝？
避免一起使用接缝的一种方法是保持调用依赖图的深度非常低.可以说是水平编码而不是垂直编码.在"叶子"功能中尽可能多地保留应用程序逻辑; 并确保除了将数据传递给其他节点/叶子函数之外,"节点"函数不起作用.然后,只测试"叶子"功能; 将"节点"功能留给集成测试.这种方法有效吗？
今天最大的软件仍然是用过程语言编写的.必须采用一些有效的方法.有经验的大型软件在程序语言方面具有良好的单元测试能够评论吗？
函数式语言具有模块化的其他结构(而不是对象),例如ML仿函数."依赖注入"基本上是"抽象事物"的美化名称,并且已经在功能语言中使用了很长时间.
在所有范例中,测试都应遵循规范边界.如果你知道给定的一段代码(函数,方法,对象......)应该做什么,你应该测试这个规范.对于叶子函数,这将是单元测试,对于"节点"函数,如果你愿意,这可以被认为是"集成测试",但它实际上是相同的活动.
我想你会发现相同的方法基本上适用于函数式编程,结果基本相同; 特别是,(重新)设计易于测试的代码也改善了其模块性和可维护性.