BDD主要用于集成测试吗？

Question

BDD主要用于集成测试吗？

16

一个常见的故事

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

鉴于测试范围如此广泛，如果我模拟系统组件（例如数据库）以执行测试，则这样做没有任何意义，因此我可以说人们主要在集成测试中使用BDD吗？

- Ryan

4个回答

10

您的例子是一个用户故事，描述了验收测试。验收测试可以具有端到端的范围，但不一定如此。验收测试和集成测试之间的核心区别在于它们的关注点。验收测试侧重于业务，并且可以被非技术人员（客户）编写/阅读。另一方面，我们还有以开发为重点的集成测试，仅验证两个或多个组件能够协同工作。

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

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

- Sergey Berezovskiy

3

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

集成测试被认为是BDD的一步。集成测试也可以存在于BDD的上下文之外。由于集成测试可用于覆盖应用程序的高级行为而不需要进行单元测试，因此集成测试非常重要。

行为是关于系统组件之间的交互，因此模拟的使用对于高级TDD至关重要。当开发人员意识到TDD是关于定义行为而不是测试时，他们开始具备TDD方面的专业知识。

用户故事可能具有广泛的范围，因为开发人员始终优先考虑开发人性化的软件。它将极限编程的实用方法与基于宏观级别分析的充分前期思考相结合，以实现宏观级别规划。

- 0o'-Varun-'o0

2

集成测试是我们主要使用BDD的地方 - 通过Selenium进行UI测试。虽然实际上我们没有用这些测试来模拟任何东西，因为BDD场景被用于驱动SpecFlow，进而驱动Selenium Webdriver执行用户旅程，如登录、点击菜单链接、创建记录等。事实上，我正在尽力在可能的情况下，尽可能地通过UI完成所有操作。

我一直在与业务分析师合作，以BDD的方式编写他们的用户故事（实际上，这已经成为我们与客户的合同条款之一），在以BDD的方式编写故事期间，我们发现了一些边缘情况，如果我们将需求推断为原子步骤（Given、When、Then），这些情况可能不会被考虑到。当我们有一个更普遍的语言来表达需求时，这对企业和开发人员来说都是双赢的局面。

- Christh

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Lunivore · Accepted Answer

这是我的术语。

场景: 用户使用系统的示例，所有相关组件都已就位而不是模拟出来。可以自动化并用作验收测试，但业务、测试人员和开发人员之间的对话是BDD最重要的方面。通常使用Given / When / Then模板创建, 有时使用允许进行自然语言捕获的工具，如 Cucumber 或 JBehave。
集成测试: 跨越两个组件的边界，通常用于检查这些组件的集成完整性。例如，可以在 Web 接口的客户端和服务器层之间来回发送消息，或者检查与 Hibernate 的数据库绑定等。不一定涉及整个堆栈。一个场景可以被认为是一种特定类型的集成测试。大多数非场景集成测试不适用于 BDD，尽管您仍然可以使用 Given / When / Then 模板。
单元测试: 消费类使用另一个类的示例，通常会将协作者模拟出来。也可能是消费类将工作委托给其协作者的示例。无论在哪个层级上进行 BDD，我们都是这样谈论它的。也可以使用 Given / When / Then 语法。
故事: 通过功能的切片，使我们能够更快地获得反馈。可以使用多个场景来说明功能的行为，并且这些场景也可以用于帮助切割功能。通常使用 作为一个...我想要...以便... 模板或 Feature Injection 的 为了...作为一个...我想要... 模板进行说明。
特性: 特性代表用户使用我们提供给他们的功能的方式。这是我们开始定义具体实现和 UI 的阶段。一个特性可以是一个网页、网页的一部分、Windows UI 中的模块、应用程序的一部分等。
能力: 用户可以使用系统实现的功能，或者系统可以实现的功能。例如：用户可以预订交易，系统足够安全，能够抵御黑客攻击。在这个层面上构思场景有助于使它们独立于 UI 并保持业务语言。

希望这有所帮助。