单元测试类VS方法

Question

单元测试时，测试类或单个方法是否更好？

大部分我见过的例子，除了从其他类中测试类之外，嘲笑类之间的依赖关系。我玩过的另一种方法是你没有测试的模拟方法（通过覆盖），这样你只用一种方法测试代码。因此，1个错误会破坏1个测试，因为这些方法是相互隔离的。

我想知道是否有一个标准方法，以及是否存在隔离每个测试方法而不是隔离类的大缺点。

Answer 1

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

所以，不要相信任何人认为定义意味着只有一种方法可以独立于上下文来做事情;有多种方式，其中一些有时比其他更有用。大概每个聪明人会争辩的方法都至少有某种价值。

硬件的最小单位是原子或可能是一些亚原子粒子。有些人测试软件就像他们在扫描每个原子，看看量子力学的定律是否仍然存在。其他人采取战舰和see if it floats。

之间的东西很可能会更好。一旦你知道你正在生产的东西超越'软件'，你就可以开始制定一个适合你应该做的计划。

Answer 2

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

这会让您确信其一部分代码正在做预期的工作。

这也是测试过程的第一部分。它有助于尽早捕捉那些烦人的bug，并通过单元测试来证明它更容易解决问题。

Answer 3

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

测试个别方法的一个缺点是您可能无法测试对象的实际行为。如果嘲笑某些方法不准确，可能无法检测到。另外嘲笑是很多工作，并且他们倾向于使测试非常脆弱，因为它们使得测试关心很多具体的方法调用发生。

在我自己的代码中，我尝试尽可能将基础结构类型的依赖关系与业务逻辑分开，以便我可以完全编写业务逻辑类的测试而不会模拟。如果你有一个令人讨厌的遗留代码库，那么测试单个方法和模拟对象的任何协作方法可能更有意义，以便将这些部分彼此隔离。

理论上，物体应该是有凝聚力的，所以对它们进行整体测试是有意义的。在实践中，很多事情并不特别面向对象。在某些情况下，模拟协作者方法比模拟由协作者调用的注入依赖关系更容易。

Answer 4

根据定义进行单元测试是测试您可以编写的最小的一段代码。 “单位”不是他们是方法的类。

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

如果你按照上面的规则，你最终会到达课堂互动的覆盖范围。只要你为每种方法写1次测试，你也会覆盖课堂互动。