以下概念及实例有部分参考自Cucumber官方书籍The Cucumber for Java Book
概念解析
自动化验收测试-Automated Acceptance Tests
自动化验收测试的想法源于极限编程(XP-Extreme Programming),特别是在测试驱动开发(TDD-Test-Driven Development)的实践中。
客户(stakeholder)不再仅仅将业务需求传递给开发团队却没有反馈的机会,而是通过开发人员和客户合作编写表达客户希望的结果的自动化测试,我们把这一点称为验收测试,因为它表达了软件需要实现什么才能使客户认为它可以接受。
这些测试与单元测试(Unit Test)不同,单元测试针对开发人员,并帮助其检查软件的设计。有时候,单位测试确保我们在做正确的事情,而验收测试确保我们事情的做法是正确的。
Unit tests ensure you build the thing right, whereas acceptance tests ensure you build the right thing.
自动验收测试可帮助开发团队保持专注,确保工作的推进,每次迭代都是团队可能做的最有价值的事情。行为驱动开发-Behavior-Driven Development
最佳的TDD实现者从外部工作,从客户的角度出发,从客户验收测试失败来描述系统的行为。 作为BDD实现者,则需要谨慎地将验收测试写为团队中任何人都可以阅读的示例。 我们利用编写这些例子的过程,从客户获得有关我们在开始之前是否在做正确的事情的反馈。 在这样做的时候,会刻意地开发一种共同的,无所不在的语言来谈论系统。Cucumber原理
Cucumber正是一种出众的验收测试工具,并借助Gherkin作为编写这些验收测试的辅助语言。
当运行Cucumber时,它会从简单的语言文本文件(称为feature
)读取您的需求,检查它们以供测试场景(称为scenario
),并针对您的系统运行这些scenario。 每个scenario都是Cucumber工作的步骤清单。
所以Cucumber可以理解这些feature文件,他们必须遵循一些基本的语法规则,这套规则的名称便是Gherkin
。
如果步骤(称为step
)定义中的代码执行没有错误,Cucumber进行到scenario的下一个step。 如果在scenario结束时没有任何出现错误的step,则会将该scenario标记为已通过。 但是,如果方案中的任何step失败,则Cucumber将scenario标记为失败并移至下一个step。 随着scenario的运行,Cucumber打印出结果,显示出哪些是可以通过的,而哪些存在错误。
Cucumber入门实例
希望通过这个实例,使初次接触Cucumber的Java开发者体会借助其进行自动化测试的整个流程,并理解各关键思想的意义。