0

假设我正在使用现有代码库中的一些代码开发新功能。我正在测试我的设计，所以我对我的功能部件进行了独立的测试，其中包括 stubbed/mocked 的合作者。现在我想测试他们是否很好地一起玩。

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

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

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

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

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

问这个问题的触发因素是保持我所有的测试都变得越来越困难，我认为我在某个地方失败了。代码中的每一次中等更改都会导致大量测试失败。我想知道我做错了什么。

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

4

1 回答 1

1

反思为什么你的测试如此脆弱。（我的一些想法..虽然针对端到端测试）。我需要有关您的情况的更多信息来提出补救措施。

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

我目前的方法是

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

更多信息：

于 2012-06-22T11:14:26.773 回答