unit-testing - 单元测试类 VS 方法

Question

在进行单元测试时，测试一个类或单个方法是更好的做法吗？

我见过的大多数示例都将类与其他类分开测试，模拟类之间的依赖关系。我玩过的另一种方法是模拟您未测试的方法（通过覆盖），以便您仅在一种方法中测试代码。因此，由于这些方法彼此隔离，因此 1 个错误会破坏 1 个测试。

我想知道是否有标准方法，以及隔离每种测试方法而不是隔离类是否有任何重大缺点。

Answer 1

短语单元测试来自硬件系统测试，并且在应用于软件时或多或少是无语义的。它可以用于任何事情，从单个例程的隔离测试到使用内存数据库以无头模式测试完整系统。

因此，不要相信任何认为该定义意味着只有一种方法可以独立于上下文来做事的人；有多种方法，其中一些有时比其他方法更有用。并且大概每个聪明人会主张的方法至少在某处具有一定的价值。

最小的硬件单位是原子，或者可能是一些亚原子粒子。有些人测试软件就像他们扫描每个原子一样，看看量子力学定律是否仍然成立。其他人坐战舰，看看它是否漂浮。

介于两者之间的东西很可能会更好。一旦你对你正在生产的东西有所了解，而不是“它是软件”，你就可以开始制定一个适合你应该做的事情的计划。

Answer 2

单元测试的重点是测试一个代码单元，即类。

这使您确信它的部分代码正在执行预期的操作。

这也是测试过程的第一部分。它有助于尽早发现那些讨厌的错误，并进行单元测试来证明它可以更容易地进一步修复它。

Answer 3

可能没有一个标准答案。单元测试是给开发人员的（或者他们应该是），做对你最有帮助的事情。

测试单个方法的一个缺点是您可能无法测试对象的实际行为。如果某些方法的模拟不准确，则可能无法检测到。模拟也是很多工作，它们往往使测试非常脆弱，因为它们使测试非常关心发生了什么特定的方法调用。

在我自己的代码中，我尽可能尝试将基础设施类型的依赖项与业务逻辑分开，这样我就可以完全编写业务逻辑类的测试而无需模拟。如果您有一个令人讨厌的遗留代码库，那么测试单个方法并模拟对象的任何协作方法可能更有意义，以便将各个部分相互隔离。

从理论上讲，对象应该是有凝聚力的，因此将它们作为一个整体进行测试是有意义的。在实践中，很多东西并不是特别面向对象的。在某些情况下，模拟协作者方法比模拟被协作者调用的注入依赖项更容易。

Answer 4

根据定义，单元测试是测试尽可能小的书面代码。“单位”不是类，它们是方法。

每个公共方法都应该至少有 1 个单元测试，专门测试该方法。

如果您遵循上述规则，您最终将到达涵盖类交互的地方。只要您为每个方法编写 1 个测试，您也将涵盖类交互。