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最重要的方面.通常使用Given/When/Then模板创建,有时使用允许自然语言捕获的工具,如Cucumber或JBehave.

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

• 单元测试:使用另一个类的消费类的示例,通常与协作者进行模拟.也可以是消费类如何委托其协作者工作的示例.无论如何,这就是我们在BDD中谈论它的方式(你可以在两个级别都做BDD).可以同时使用鉴于/时/然后语法.

• 故事:通过功能切片,让我们获得更快的反馈.可以用若干场景来说明特征的行为,并且这些场景也可以用于帮助切割特征.通常用As表示...我想要......那样......模板,或者......为了......作为......我想... 特征注入的模板.

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

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

希望这可以帮助.

Answer 2

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

回到BDD.它可用于验收测试(功能级别)和单元测试(代码级别).对于不同级别的BDD,甚至有不同的工具:

• SpecFlow(验收测试)
• NSpec,NBehave(单元测试)