Category Archives: Testing


Gherkin是一个Domain Specific Language, 它以一种跟自然语言类似的方式来描述业务,因此可以作为BDD的测试用例的描述语言。Gherkin来源于 Cucumber, Cucumber是基于 ruby实现的一个GEM。





BDD的开发模式跟TDD类似,但是测试的层次较高,不在unit level, 而在story level,端到端的测试。BDD的实现,大多基于Gherkin的语法(语法来自于Cucumber), 但是还有其他的框架也是实现了这个语法。下面简单介绍了Gherkin和各种语言的BDD引擎。

Behavior Driven Development (which we will now refer to as “BDD”) follows on from the ideas and principles introduced in Test Driven Development. The key points of writing tests before code really apply to BDD as well. The idea is to not only test your code at the granular level with unit tests, but also test your application end to end, using acceptance tests.

Gherkin Syntax

Acceptance tests usually make use of the Gherkin Syntax, introduced by the Cucumber Framework, written for Ruby. The syntax is quite easy to understand, and, in the Freshen Python package, makes use of the following eight keywords to define your features and tests:

  • Given
  • When
  • Then
  • And
  • Feature:
  • Background:
  • Scenario:
  • Scenario Outline:

Below, you can review these keywords in action, and how they can be used to structure your acceptance tests.

BDD Engine

Cucumber is not the only engine supporting natural language instructions. It’s just one implementation of natural language instructions interpreter. The actual language to write tests with is called Gherkin. And it has different implementations adopted to different programming language. Thus we have:




Project Sikuli:



T-Plan Robot:











How to implement UI testing without shooting yourself in the foot

作者是明显不认同做UI automation testing的,但是很多人都愿意这么做,所以作者也给出了几条做UI automation testing的原则。

Things to remember

To avoid shooting yourself in the foot with UI tests, remember these things:

* Think about UI test automation at three levels: business rules, user interface workflow and technical activity
* Even if the user interface workflow automation gets implemented in plain text, make sure to put one level of abstraction above it and describe business rules directly. Don’t describe rules as workflows (unless they genuinely deal with workflow decisions – and even then it’s often good to describe individual decisions as state machines).
* Even if the user interface workflow automation gets implemented in code, make sure to separate technical activities required to fulfil a step into a separate layer. Reuse these step definitions to get stability and easy maintenance later.
* Beware of programming in plain text.

CI server的选择

持续集成(continuous integration)服务器的选择:

CruiseControl (
Hudson (
LuntBuild (
TeamCity (
AntHill Pro (
Bamboo (
QuickBuild (