如何在BDD中模拟/模拟什么

Question

我知道Dan North设计BDD的意图之一是将词汇表从复杂的测试域中移开。然而，在实现由外到内的方法时，我们似乎仍然需要对模仿行为（或者，如果您愿意的话）有一些了解。North在这个视频中建议，如果我从最外层的域对象开始，然后向内工作，我会在发现合作者时模仿它们，然后用适当的实现替换它们。所以最后，我以一组端到端测试结束。

Martin Fowler在这篇博客文章中定义了TDD的两个阵营：“古典TDD”，在可能的情况下使用真实对象，在必要的情况下使用模拟对象；“模拟TDD”，在大多数情况下更喜欢模拟对象。他认为BDD倾向于后者。也就是说，在开发一个特性的最后，“mockist”方法将在实际测试中留下mocks（抱歉在BDD讨论中使用这个词）。

公平地说，这两种材料都有多年的历史了，也许随着BDD在单位级别和接受级别之间的发展，事情变得更加清晰。

因此，似乎我的抽象方法将是模拟某些协作者（或提供一个“测试替身”），某些场景可能比其他场景更多地使用他们。例如，我是否总是模拟外部资源，如数据库或邮件服务器？

也许我问错问题了。BDD是关于沟通，缩短反馈周期，发现你不知道的东西。只要我们感兴趣的行为真的起作用，什么和什么不是可以模仿的是一个无关紧要的问题。我很好奇别人在这里的做法是什么。

Answer 1

对我来说，BDD允许我验证我已经构建了正确的东西。这意味着，如果我将应用程序插入到一个真实的数据库并使用真实的UI，它的行为应该是正确的。那就是你所说的首尾相接。

现在，如果我将应用程序插入内存存储，并通过API级别（就在UI下面）与应用程序进行对话。我会期望它表现得完全一样。

这就是问题所在，我们需要弄清楚我们所说的行为是什么意思，当我们做BDD时，我们感兴趣的行为是什么。

在我的例子中，如果我从用户故事开始并编写场景，我主要感兴趣的是应用程序API、服务层、域实体、helper等的行为...主要是我对UI或数据库中会发生什么不太感兴趣。真正的肉是在服务器端编写的所有代码。这就是我感兴趣的行为。如果你这样想，去掉UI和DB是有意义的，因为我们不关心这些家伙。UI的预期行为是显示应用程序提供的数据。UI是一个愚蠢的东西。数据库的预期行为是存储和检索应用程序提供或需要的实体。那也是一件很蠢的事。现在其他的一切，这就是所有聪明的地方，我要负责。

因此，我很乐意在没有UI的情况下运行BDD场景，并使用存储库的内存版本。我从中得到的好处是非常非常快速、专注和可维护的测试。

关于UI和DB，我会编写javascript单元测试来测试其中的行为，今天一些UI可以有很多显示逻辑来隐藏和显示东西，但这种行为不同于我的用户故事bdd场景中的行为（他们不应该谈论UI）。