TDD -如何定义具有独立单元测试的集成测试范围？
假设我正在使用现有代码库中的一些代码来开发新特性。我正在测试如何驱动我的设计，所以我对我的特性部件使用了带有存根/模仿的协作者的独立测试。现在我想测试他们是否在一起玩得很好。
我是否应该用连接在一起的所有真正的依赖项来编写一个巨大的测试(除了外部系统等)？换句话说，我应该为整个故事编写集成测试，还是将其分割成几个较小的部分，测试，假设3-4个对象一起玩，只做这个故事的一部分？然后，我最终会为整个特性编写测试，从头到尾。但是，我应该在一个测试用例中执行多少个对象的协作呢？
如果是后者，我需要准备安装程序(连接依赖项，存根部分)，为每个测试准备测试数据和预期条件。现在往上走(在更高层次上对越来越多的模块进行分组)，我仍然需要在某种程度上“复制”这个准备步骤。这“复制”不是很糟糕吗？
我说的是“测试级别”，如下所示：
---------------------------------------------------------------
| ------------------------------------
|| ------ ------ |
|| |unit| |unit| units integration |
|| ------ ------ |
|------------------------------------- integration of some
| already integrated
|------------------------------------- units, etc
|| ------ ------ |
|| |unit| |unit| units integration |
|| ------ ------ |
|-------------------------------------
|---------------------------------------------------------------同样，正如TDD实践者所说的“经典”(而不是“嘲弄者”)，我应该尽可能多地使用真正的实现。但是，测试对象具有3个级别的依赖关系，并且最终具有DB或外部系统，这意味着我仍然必须对某些内容进行存根/模拟。那么，我是否应该在结束时只嘲笑这种繁重的/外部服务呢？
问这个问题的触发因素是，让我的所有测试保持不变变得越来越困难，而且我认为我在某个地方失败了。代码中的每一次介质更改都会导致大量测试失败。我想知道我做错了什么。
预先感谢所有的提示和答案。
回答 1
Stack Overflow用户
发布于 2012-06-22 11:14:26
想想为什么你的测试如此脆弱。(一些我的思想.虽然是针对端到端的测试)。我需要更多关于你情况的信息才能提出补救办法。
如果功能中断，测试就会失败--如果您重构代码，即通过行为保持转换来更改结构，那么您的测试就不应该中断。
我现在的方法是
- 有许多微小的、聚焦的、超快的单元测试(如果您将每个类从其依赖项中分离出来的话，则进行微测试)。这应该是测试的主要部分。
- 集成测试:参考端口和适配器(六角形)体系结构。您的应用程序与外部子系统(如数据库或Web)接口。清晰地定义应用程序和子系统之间的接口。接下来，编写集成测试，以验证插入到端口的任何实现是否符合您的约定(例如，您将测试MySqlDataRepository实际上可以通过对真实DB进行测试来持久保存信息)。通过这样做，您可以验证MySqlDataRepository是否有效。现在你所有的单元测试都不需要慢。您可以使用mockDatabase而不会失去任何信心。
- 最后，您需要几个端到端的测试来验证所有的部分都是正确连接的。正如你所说，这将是最慢和最痛苦的维持。但是，它们是有价值的；通过选择正确的测试来运行端到端，可以将维护的麻烦降到最低。
更多信息：
- http://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid
- https://stackoverflow.com/a/3382235/1695
https://stackoverflow.com/questions/11147273
复制相似问题
腾讯云开发者
