BDD主要用于集成测试吗？

Question

一个常见的故事

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

考虑到如此广泛的覆盖范围，如果我模拟系统组件（如DB）以执行测试是没用的，那么我可以说人们主要在集成测试中使用BDD吗？

Answer 1

这是我的术语。

• 场景：使用系统的用户示例，其中包含所有相关组件而非模拟。可以自动化并用作验收测试，但业务，测试人员和开发人员之间的对话是BDD最重要的方面。 Often created using the Given / When / Then template，有时用于允许自然语言捕获的工具，例如Cucumber或JBehave。

• 集成测试：跨越两个组件的边界，通常用于检查这些组件的集成的完整性。例如，可用于在Web界面的客户端和服务器层之间来回发送消息，或者用Hibernate等检查数据库绑定。不一定涉及完整堆栈。场景可以被认为是一种特定的集成测试。 BDD并不真正适用于大多数非场景集成测试，尽管您仍然可以使用Given / When / Then模板。

• 单元测试：使用其他类的消费类示例，通常是协作者被模拟出来的。也可以是消费类如何委托其协作者工作的示例。无论如何，这就是我们在BDD中谈论它的方式（你可以在两个级别都做BDD）。可以also use the Given / When / Then syntax。

• 故事：通过功能切片，以便我们获得更快的反馈。可以用若干场景来说明特征的行为，并且这些场景也可以用于帮助切割特征。经常用作为一个... ...我希望......那样...... 模板，或者为了......作为......我想...... / em> Feature Injection的模板。

• 功能：功能代表用户使用我们提供的功能的方式。这是我们开始定义具体实现和UI的阶段。功能可以是网页，网页的一部分，Windows UI中的模块，应用程序的一部分等。

• 能力：用户可以通过系统实现的功能，或系统可以实现的功能。即：用户可以预订交易，系统足够安全以抵御黑客。此级别的短语场景有助于他们独立于用户界面，并将其保留在业务语言中。

希望这有帮助。

Answer 2

您的示例是一个用户故事，描述了验收测试。验收测试可能具有端到端的范围，但不一定如此。接受和集成测试之间的核心差异是他们关注的重点。验收测试以业务为中心，可由非技术人员（客户）编写/读取。另一方面，我们有专注于开发的集成测试，它只是验证两个或多个组件可以一起工作。

回到BDD。它可用于验收测试（功能级别）和单元测试（代码级别）。对于不同级别的BDD，甚至有不同的工具：

• SpecFlow（验收测试）
• NSpec，NBehave（单元测试）

Answer 3

行为驱动开发正在思考特定场景中产品的行为。它扩展了测试驱动开发和域驱动设计。此外，BDD正在考虑超越集成测试。 BDD旨在最大化用户，开发人员，测试人员，经理和分析师之间的沟通。

集成测试被视为BDD的一个步骤。集成测试也可以在BDD的上下文中存在。由于集成测试可用于覆盖应用程序的高级行为，而无需进入单元测试。

行为是关于系统组件之间的交互，因此使用模拟是高级TDD的基础。 TDD的专业知识开始曙光，开发人员意识到TDD是关于定义行为而不是测试。

用户故事可能具有广泛的范围，因为它始终是开发人性化软件的优先事项。它结合了极限编程的实用方法和基于宏观水平分析的足够前沿思维，以实现宏观水平规划。

Answer 4

集成测试是我们主要使用BDD进行的 - 使用Selenium进行UI测试。虽然实际上我们并没有使用这些测试来嘲笑任何东西，因为BDD场景用于驱动SpecFlow来驱动Selenium Webdriver来执行用户旅程，例如登录，单击菜单链接，创建记录。事实上，我尽可能努力通过用户界面尽一切努力。

我一直在与业务分析师合作，以BDD方式撰写他们的用户故事（实际上它现在与我们的客户签订合同），在编写故事时发现它非常令人耳目一新在BDD方式中，我们发现当我们将需求推断为原子步骤（Given，When，Then）时可能无法想到的边缘情况。当我们使用更通用的语言来表达需求时，对于业务和开发人员来说，这确实是一个双赢的场景。