Question

假设我正在使用现有代码库中的一些代码来处理新功能。我正在测试我的设计，所以我为我的功能部件进行了隔离/模拟协作者的隔离测试。现在我想测试他们是否很好地一起玩。

我应该写一个巨大的测试，将所有那些真正的依赖关系连接在一起（除了一些像外部系统等）？换句话说，我应该为整个故事编写集成测试，还是将它分成几个较小的部分，测试让我们说3-4个对象一起玩这个故事的一部分？然后我终于从头到尾为整个功能编写测试。但是我应该在一个测试用例中练习多少个对象的协作？

如果是后者，我需要准备设置（线路依赖，其中一些存根），为每个测试准备测试数据和预期条件。现在进入上层（在更高层次上分组越来越多的模块）我仍然需要以某种方式“复制”这个准备步骤。这不是“重复”不好吗？

我说的是“测试级别”，如下所示：

---------------------------------------------------------------
| ------------------------------------
|| ------  ------                    |
|| |unit|  |unit|  units integration |
|| ------  ------                    | 
|-------------------------------------     integration of some
|                                          already integrated
|-------------------------------------     units, etc
|| ------  ------                    |
|| |unit|  |unit|  units integration |
|| ------  ------                    | 
|-------------------------------------
|---------------------------------------------------------------

同样作为“经典”（而不是“嘲笑者”）TDD从业者说，我应该尽可能多地使用真正的实现。但是，然后测试具有3级依赖关系并且最终具有DB或外部系统的对象意味着我仍然需要存根/模拟某些东西。那么我应该在最后只模拟这种重/外部服务吗？

提出这个问题的触发器是，保持我所有的测试都变得越来越困难，我想我在某处失败了。代码中的每次介质更改都会导致一堆测试失败。我想知道我做错了什么。

提前感谢所有提示和答案。

Answer 1

反思为什么你的考试是如此脆弱。（部分my thoughts ..虽然针对端到端测试）。我需要更多关于你情况的信息来提出补救措施。

如果功能被破坏，测试应该失败 - 如果您重构代码，即通过保持行为的转换来改变结构，那么您的测试不应该破坏。

我目前的方法是

有许多微小的，专注的，超快速的单元测试（如果你将每个类与其依赖关系隔离，则微观测试）。这应构成您的大部分测试
集成测试：请参阅端口和适配器（六边形）体系结构。您的应用与外部子系统接口，例如数据库或Web ..清楚地定义应用程序和子系统之间的端口（接口）。接下来编写集成测试，验证插入端口的任何实现是否符合您的合同（例如，您将测试MySqlDataRepository是否可以通过针对真实数据库进行测试来实际保留信息）。通过这样做，您验证MySqlDataRepository的工作原理。现在你所有的单元测试都不需要很慢..你可以使用mockDatabase而不会失去任何信心
最后，您需要进行一些端到端测试，以验证所有部分是否正确连线。正如你所说，这些将是最慢和最痛苦的维持。但它们有价值;通过选择正确的测试来端到端运行，您可以最大限度地减少维护麻烦。

更多信息：

TDD - 如何定义具有隔离单元测试的集成测试范围？

1 个答案: