我是否应该为A类编写测试，如果它属于B类

Question

我想对测试方法有一些看法。

让我们假设我们有A类和B类.B类使用A类的功能.B类经过全面测试，因此一些测试覆盖也间接应用于A类。

我应该直接为A级写完整的测试吗？或者我应该只测试未测试的A类功能吗？

我在问，因为将来可能会删除或修改B类，因为它可能不会使用A类中的相同功能，因此可能会留下一些未经测试的方法。你会做什么？

Answer 1

是的，你应该全面测试A。

1. B可能会在某个时刻发生变化，因为它现在使用A并不意味着它总会如此。

2. B可能无法使用A的所有功能，这意味着您没有测试所有代码。

Answer 2

CLASSES！= UNITS

如果你练习一个好的TDD，你会很容易理解背后的内容。

---

IMO，您应该在不基于B已经过测试的事实的情况下测试A的行为。

实际上，有三种情况：

A和B属于同一层：

• 如果A是通过B的重构周期（提取类）创建的（通常在练习一个好的TDD时发生），那么A应该完全没有经过测试！根本不需要测试！
  实际上，代码结构（在这种情况下，类/ SRP的分离）应该独立于 Unit 概念;在这种情况下，B和A属于同一单位。

• 如果A存在之前 B，则B不应基于此事实，B的整个行为应该进行测试。

A和B不属于同一层（例如，不同的boundaries）：

• 如果B是一个GUI类，A是一个商务类，那么在测试A和B时应该加倍/模拟A应该有专门的测试。
  实际上，域架构不应与behavior/feature概念混合在一起。

要了解原因，请阅读Bob最近关于这个概念的文章：

http://blog.8thlight.com/uncle-bob/2014/01/27/TheChickenOrTheRoad.html?utm_source=hootsuite&utm_campaign=hootsuite

摘录：

  

一种常见的误解是测试的设计必须反映出来   生产代码的设计。作为作者，TDD不要求   建议，“系统中的每个单元都与一个   精心设计的单元测试。“的确，这是其中一个原因   我们中的许多人已经停止称他们为“单位”测试。

注意：TDD并不关心“未来”，相反，它可以帮助您编写尽可能多的代码，而不是更多。所以你不应该担心这个：

  

将来B类将有可能成为   删除或修改

如果您编写了良好的测试（我更喜欢“specs”一词），则会立即检测到此类删除。

Answer 3

肯定为A级写完整的测试。你在这里回答了你自己的问题：

(...)maybe in the future there will be possibility that the B class will be removed or modified in the way that it might not use the same functionality from A class so it might leave some methods untested.

Answer 4

单元测试背后的一般思想是每个单元由一个工作单元组成。这可以像方法一样小，也可以像几种方法一样大。

您已经涵盖了B依赖于A的场景，但是从您的故事中我们可以假设A也将单独使用。因此，A也应该进行测试，因为它是一个单独的工作单元。

Answer 5

B应该只通过接口IA使用A

通过它的公共界面测试B，通过它的公共界面测试A.

两者都应该进行测试。

Answer 6

我认为你的答案就在那里：
in the future there will be possibility that the B class will be removed or modified
我认为对于A的测试套件来说这是一个很好的例子。

Answer 7

你应该首先测试A，然后 B.如果你在B上遇到测试失败，你就没有足够的诊断来知道它是否来自B的代码或在A的。

单元测试不只是“通过/失败”，它们非常关于诊断问题。