一个共同的故事
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吗?
一个共同的故事
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吗?
这是我的术语。
场景:用户使用系统的示例,所有相关组件都已就位而不是模拟出来。可以自动化并用作验收测试,但业务、测试人员和开发人员之间的对话是 BDD 最重要的方面。通常使用Given/When/Then模板创建,有时在允许自然语言捕获的工具中创建,例如Cucumber或JBehave。
集成测试:跨越两个组件的边界,通常用于检查这些组件的集成完整性。例如,可用于在 Web 界面的客户端和服务器层之间来回发送消息,或检查与 Hibernate 的数据库绑定等。不一定涉及整个堆栈。一个场景可以被认为是一种特殊的集成测试。BDD 并不真正适用于大多数非场景集成测试,尽管您仍然可以想象使用 Given / When / Then 模板。
单元测试:使用另一个类的消费类的示例,通常将协作者模拟出来。也可能是消费类如何将工作委托给其合作者的一个例子。无论如何,这就是我们在 BDD 中谈论它的方式(您可以在两个级别上进行 BDD)。也可以使用 Given/When/Then 语法。
故事:通过一个功能让我们获得更快的反馈。一个特征的行为可以用几个场景来说明,这些也可以用来帮助分割特征。通常用As a... I want... So that...模板或为了... as a... I want... Feature Injection模板来说明。
功能:功能代表用户使用我们提供给他们的功能的方式。这是我们开始定义具体实现和 UI 的阶段。特征可以是网页、网页的一部分、Windows UI 中的模块、应用程序的一部分等。
能力:用户可以通过系统实现的东西,或者系统可以实现的东西。即:用户可以预订交易,系统足够安全,可以抵御黑客。此级别的短语场景有助于它们独立于 UI 并使它们保持在业务语言中。
希望这可以帮助。
您的示例是一个用户故事,它描述了验收测试。验收测试可以有端到端的范围,但不一定。验收测试和集成测试之间的核心区别在于它们关注的内容。验收测试以业务为中心,可由非技术人员(客户)编写/阅读。另一方面,我们有以开发为中心的集成测试,它只是验证两个或多个组件可以一起工作。
回到 BDD。它可以用于验收测试(功能级别)和单元测试(代码级别)。对于不同级别的 BDD,甚至还有不同的工具:
行为驱动开发正在考虑产品在给定场景中的行为。它扩展了测试驱动开发和领域驱动设计。BDD 也在考虑集成测试之外的问题。BDD 是关于最大化用户、开发人员、测试人员、经理和分析师之间的沟通。
集成测试被认为是 BDD 的一个步骤。集成测试也可以存在于 BDD 的上下文之外。因为集成测试可用于覆盖应用程序的高级行为,而无需进入单元测试。
行为是关于系统组件之间的交互,因此使用模拟是高级 TDD 的基础。当开发人员意识到 TDD 是关于定义行为而不是测试时,TDD 的专业知识开始显现。
用户故事可能具有广泛的范围,因为它始终是开发人性化软件的优先事项。它将极限编程的务实方法与基于宏观层面分析的足够的预先思考相结合,以实现宏观层面的规划。
集成测试是我们主要使用 BDD 进行的 - 使用 Selenium 进行的 UI 测试。尽管实际上我们并没有对这些测试进行任何模拟,因为 BDD 场景用于驱动 SpecFlow 进而驱动 Selenium Webdriver 执行用户旅程,例如登录、单击菜单链接、创建记录。事实上,我正在尽我最大的努力通过 UI 尽可能地完成所有工作。
我一直在努力并与业务分析师一起以 BDD 的方式编写他们的用户故事(事实上,它现在在我们与客户的合同中),在 BDD 中编写故事的过程中发现这一点非常令人耳目一新且非常有用时尚,当我们将需求外推到原子步骤(Given、When、Then)时,我们会发现可能不会被考虑的边缘情况。当我们有一种更通用的语言来表达需求时,从业务和开发人员的角度来看,这确实是一个双赢的局面。