5
单元测试是否会导致过早的泛化（特别是在C ++中）？
初步说明 我不会区分不同种类的测试，在这些站点上已经有一些与此有关的问题。 我会采取什么样的存在，并且说：单位的“测试应用程序的最小单位可分离”的意义测试从这个问题实际上导出 隔离问题 程序的最小可隔离单元是什么。好吧，正如我所见，它（高度？）取决于您所使用的语言。 Micheal Feathers谈到接缝的概念：[WEwLC，p31] 接缝是一个您可以更改程序行为而无需在该位置进行编辑的位置。 而且，在不进行细节讨论的情况下，我了解到在单元测试的上下文中存在的缝隙—在程序中可以使“测试”与“单元”进行交互。 例子 单元测试-尤其是C ++中的单元测试-要求被测试的代码添加更多的接缝，这对于给定的问题是严格要求的。 例： 在非虚拟实现就足够的地方添加虚拟接口 拆分-generalizing（？）-一个（较小的）类，进一步“恰好”以方便添加测试。 将单个可执行项目拆分为看似“独立”的库，“公正”以便于为测试而独立地编译它们。 问题 我将尝试一些可能会问相同问题的版本： 单元测试是“仅”对应用程序代码进行结构化的一种方式，这对单元测试是有益的，还是实际上对应用程序结构有利。 是需要的代码泛化作出任何它的单位可测试非常有用，但单元测试？ 添加单元测试是否会强制一个泛化？ 从问题域的角度来看，形状单元测试对代码的“总是”作用力是否也对代码总体而言是一种良好的形状？ 我记得有一条经验法则，直到您需要/直到有第二个地方使用该代码时，它才会泛化。使用单元测试，总是有第二个地方使用代码-即单元测试。那么，这个理由足以概括吗？