本文发表于infoq

什么是BDD?

BDD在wikipedia上定义如下:

BDD是第二代的、由外及内的、基于拉(pull)的、多方利益相关者的(stakeholder)、多种可扩展的、高自动化的敏捷方法。它描述了一个交互循环,可以具有带有良好定义的输出(即工作中交付的结果):已测试过的软件。

简单一点地说,BDD,即行为驱动开发,是通过与产品经理沟通需求,定义出满足这些需求的软件需具备的行为(Behaviour),再以这些行为为驱动(Driven),编写产品代码来实现这些行为。(Development)。BDD的出现,是为了解决测试驱动开发中常遇到的问题,比如:从哪里开始测试,应该测试什么,不应该测试什么,等等。想了解更多可参见Dan North的introducing BDD。

BDD实践所面临的问题

进行BDD实践首先要解决如下几个问题:

  • 如何实现一个能够描述系统行为(业务价值)、非技术人员可读的测试?
  • 如何让这个测试变得可执行?

业界对这些问题已经有了答案,JBehave, CucumberConcordian等BDD框架的出现,解决了这个问题。 这些BDD框架各自提供了一套DSL(Domain-Specific-Language),开发人员可以使用DSL描述业务需求,例如,

前置条件: 用户A账户余额1000元 用户B账户余额200元
场景:
	用户A登录系统
	向用户B转账500元
	用户A账户余额应为500元
	用户B庄户余额应为700元

同时,这些框架都依赖于Webdriver(如selenium-webdriver,watir-webdriver),BDD框架通过webdriver调用浏览器的接口,模拟用户输入,读取浏览器页面上显示的内容用于验证。

下面我们通过一个完整的例子来看看如何使用这些工具进行BDD实践的。

Cucumber与业务价值

在Behaviour Driven Development中,第一步就是把需求细分为多个任务,拿最常见的用户登录功能为例,可以划分为以下几个任务:

  • 用户名密码匹配,登录成功
  • 用户名或密码不匹配,登录失败

BDD强调“每一个测试需要体现出业务价值”,因此,可以把上述两个任务实现为两个场景:

Feature: User login
Background: There is a user with the following login detail:
	|    email      | password|
	| my@example.com|   test  |
	
Scenario: Login succeed
Given the user login with the following detail:
	|    email      | password|
	| my@example.com|   test  |
Then the user should login succeed

Scenario: Login failed
Given the user login with the following detail:
	|    email      |     password     |
	| my@example.com|   wrongpassword  |
Then the user should login failed 实际上,上面的这段代码就是使用cucumber的DSL描述的测试场景,几乎就是遵循了一定格式的英语,即使看不懂代码的产品经理、业务分析师也能够通过此文档和开发人员顺畅地交流。用Cucumber把一个需求的不同场景描述出来,也是从不同角度阐述了这个需求的业务价值。__Cucumber的目标就是书写可执行的,能够表述业务价值文档。__ 与之类似的框架还有Concordian,JBehave等。

紧接而来的问题是:如何让文档执行起来?Cucumber提供了把业务逻辑转换为可执行代码的机制——”step definition”。请看下面的例子:

Given /^the user login with the following detail:$/ do |detail|
	#omitting code…
end 这个step definition会匹配下面这个step:

Given the user login with the following detail:
	|    email      | password|
	| my@example.com|   test  |

当Cucumber feature被执行的时候,这个step definition中的代码会被执行。那么,接下来的问题就是:如何象真实用户那样打开浏览器,输入用户名密码,点击提交按钮,验证登录是否成功。这时候,该Webdriver出场了。

Web Driver与页面交互

先来看下面一段代码:

require 'watir-webdriver'
b = Watir::Browser.new
b.goto 'http://localhost:3000/login'
b.text_field(:id => 'email').set 'my@example.com'
b.text_field(:id => 'password').set 'password'
b.button(:name => 'submit').click
b.text.include? 'Login succeed'

这段代码会做如下事情:

1. 打开浏览器,访问h地址 “http://localhost:3000/login”
2. 在邮件输入框输入 “my@example.com”
3. 在密码输入框输入 “password”
4. 点击 提交按钮
5. 验证结果页面是否包含“Login succeed”字样 这就是webdriver所提供的能力,web driver通过调用浏览器的支持自动化的API,模拟真实用户在浏览器上的操作。把这段代码被放在上面的step definition中,当cucumber测试运行的时候,这段代码就会运行,完成登录操作。这个例子是使用[Watir webdriver](http://watirwebdriver.com/)实现的,另外一个比较流行的webdriver是[Selenium webdriver](http://seleniumhq.org/projects/webdriver/)。

不同Webdriver提供的API也不尽相同,而Capybara则致力于封装多种web driver之间的差异。同时,Capybara提供了一些更聪明的特性,例如,等待页面加载完成再执行下一个步骤,这对于开发人员来说非常重要,否则,就需要自己判断写代码页面加载完成,代码丑陋,测试脆弱,那将是开发人员的噩梦。

Page Model与页面建模

至此,一个可执行的描述用户登录的测试用例就编写完毕,当我们执行这个测试用例时,就会看到:

浏览器打开
访问登录页面
在页面上输入用户名
密码
点击登录按钮
登录成功
测试通过 上述所有操作都是自动完成,一切都很完美,但前提是只在这样的一个小示例里。在一个实际的项目里,我们经常会遇到下面几个问题:

1.当越来越多的与页面交互的代码出现在step definition中时,页面交互,结果验证的代码混杂在一起,代码的可读性急剧下降。
2.因为webdriver与浏览器交互时依赖于页面元素的id、name等属性,对页面元素的任何小的修改都可能会导致测试失败。
3.在多个step definition与同一个页面交互时,可能会有冗余代码。

page model的出现就是为了解决上述问题,通过对页面的属性,交互动作进行抽象,封装以达到功能重用,隔离变化的目的。请看下面的例子:

Page model定义
class PageWithLogin
	def url
		#omitting code…
	end
	
	def login email, password
		#omitting code…
	end
end

class PageWithLoginResult
	def login_succeed?
		#omitting code…
	end
end
Step定义
Given /^the user login with the following detail:$/ do |detail|
	on_page_with :login do |page|
		visit page.url		
		page.login(detail["email"], detail["password"]) 
	end
end

Given /^the user should login succeed$/ do |detail|
	on_page_with :login_result do |page|
		page.login_succeed?.should == true
	end
end

如上,把loginlogin_succeed?功能封装到PageWithLogin, PageWithLoginResult这两个page model中,当”登录页面”,“登录成功页面”的页面结构发生变化时,只需要修改page model中的实现即可,step 定义无需任何变化。关于page model,我的同事徐昊曾经专门写过一篇文章

结论

BDD框架通过提供DSL,帮助业务人员,测试人员,开发人员定义需求的验收标准,共同得到一个明确的需求完成的定义。通过和webdriver集成,使这个验收标准变得可执行,大大减少了手工验证的压力,当软件通过了这个验收标准,则意味着这个需求已经开发完成。

注解与参考

  1. The truth about BDD Robert C Marting
  2. introducting BDD Dan North
  3. BDD on Wikipedia

感谢张凯峰对本文的审校。

Character encoding

ASCII

  • encoding in 7-bit.
  • 32 -> 127 representing characters.
  • 0 -> 31 representing control characters.
  • 128 -> 255 was called OEM characters, many company has their own idea about how to use these charaters.

ANSI:

  • lower 127 characters is same with ASCII.
  • higher 127 characters were divided into different “code pages”

Unicode:

  • Code point: In Unicode, a letter maps to something called a code point which is still just a theoretical concept.
  • Encoding: Unicode Byte Order Mark: indicating encoding order is ‘high-endian’ or ‘low-endian’

UTF8: Every code point from 0-127 is stored in a single byte. Only code points 128 and above are stored using 2, 3, in fact, up to 6 bytes.

The Most Important thing:

  It does not make sense to have a string without knowing what encoding it uses. 

怎样写单元测试

最近和同事讨论过几次如何写单元测试之后,突然意识到,是要写点什么了。
什么是单元测试, 维基百科上是这么定义的: unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use.[1] Intuitively, one can view a unit as the smallest testable part of an application. 简而言之,就是验证系统中最小可测试单元的功能是否正确的自动化测试。因此,单元测试的目地就是“对被测试对象的职责进行验证”, 在写单元测试之前,先识别出被测试对象的职责,就知道该怎么写这个单元测试了。

在我看来,根据被测试对象,单元测试可以分为两大类:“对不依赖于外部资源的组件的单元测试”和“对依赖于外部资源的组件的单元测试”。由于测试的对象的不同,我们需要采用不同的测试方案:

对不依赖于外部资源的组件的单元测试

对不依赖于外部资源的组件进行测试时,我们主要关注被测试对象的状态变化是否和预期的一致,而对于其内部实现,则不用关心,举个例子:

Account account = new Account(20)
assertThat( account.withdraw(10).balance(),  is(10))

开始账户里有20元,扣款10元后余额应该是10元,我们不关心扣款是现金交易还是银行转账,我们只关心扣款功能是正常的, 这就是一种黑盒测试

对依赖于外部资源的组件的单元测试

对依赖于第三方库、组件的接口的组件进行单元测试时,需要对依赖的库进行mock,让依赖库按照约定表现不同的行为,并且,在测试中验证被测试代码是否按照约定正确的调用了第三方接口(是否调用了正确的API, 是否传递了正确的参数), 我们再来看个例子:

//AuthenticateService是一个外部部件通过Web Service暴露的用户鉴权接口,
//在单元测试中,我们使用一个mock的AuthenticateService对象,来验证UserServiceImpl中的接口调用是否正确。
AuthenticationService mockAuthService = createMock(AuthenticateService.class)
UserService userService = new UserServiceImpl(mockAuthService);
User user = new User("nicholasren", "encrypted_password");

assertThat(userService.authenticate(user), is(true));

//期望userService.authenticate中会调用AuthenticateService.authenticate, 并且传递了正确的用户名和加密后的密码
verify(mockAuthService).authenticate(user.getName(), user.getPassword())

上面的例子中,对于依赖于外部资源的组件,我们需要验证的是该组件调用了正确的第三方接口,并且传入了正确的参数,这就是一种白盒测试

对依赖于框架的组件的单元测试

我把这种情形也归类为“依赖于外部资源的组件的单元测试”,但是特殊的是,被测试对象依赖的是框架,而这个框架代码在单元测试运行是不会被执行,我们来看个例子:

  //load.js
  $('.trigger').click(loadItems)

  //...
  loadItems:function() {
    var ajaxLoading = $("<li class='ajax-loading' style='display:block;'>Loading...</li>");
    var itemContainer = $(".container");
    $.ajax({
      url: this.config.itemLoadingUrl + groupID,
      type: 'GET',
      beforeSend: function(){
        itemContainer.append(ajaxLoading);
      },
      complete: function(){
        ajaxLoading.remove();
      },
      success: function (data) {
        itemContainer.append(data);
      },
      error: function () {
        itemContainer.append("<li class='error' style='display:block;'>Oops, connection time out. Please try again later.</li>");
      }
    });
  }

$.ajax 是jquery提过的发送ajax请求的方法,然而,在spec中,我们无法真正地发送ajax请求,然后再进行验证,于是我们stub了这个方法。 这时候,就有个问题了:
真正的$.ajax()方法没有被调用,complete,success,error的这几个function都没有被调用,那么这些function中的逻辑该如何测试呢?

$.ajax是jquery提供的API,出现错误的机率是非常非常低的,因此,我们可以假设$.ajax是正常工作的,然后stub $.ajax, 当被测试代码中调用$.ajax时,让其调用我们stub的一个fake function. 例如,我们想测试ajax request失败时,是否正确地显示了错误信息,那么我们可以写出下面的测试:

  //load_spec.js
  it("should show error message when ajax request failed", function(){
    spyOn($, "ajax").andCallFake(function(params) {
      params.beforeSend();
      params.complete();
      params.error("", "404");
    });
  
    var trigger = $(".itemContainer .trigger");
    trigger.click();
  
    expect($(".itemContainer  .error").length).toBe(1);
    expect($(".ajax-loading").length).toBe(0);
  });

$.ajax 是jquery提过的发送ajax请求的方法,然而,在spec中,我们无法真正地发送ajax请求,然后再进行验证,于是我们stub了这个方法。 这时候,就有个问题了:
真正的$.ajax()方法没有被调用,complete,success,error的这几个function都没有被调用,那么这些function中的逻辑该如何测试呢?

$.ajax是jquery提供的API,出现错误的机率是非常非常低的,因此,我们可以假设$.ajax是正常工作的,我们可以stub $.ajax,传入了一个fake function,在这个fake function中执行我们期望的行为,然后验证这些function的执行效果。

使用jasmine的spyOn机制,传入一个fake function,在此function中依次执行 beforeSend, complete,error 这几个callback,(注意上面andCallFake里的三行,这也是真实情况下ajax 请求失败时,这些callback被执行的顺序),然后验证error这个callback是否显示了error message。

因此,对于依赖于外部API的组件的测试,当此API在单元测试中不能被执行,我们可以假设其API工作正常,通过测试代码模拟其API执行的情况, 验证被测试对象的行为

一句话,写单元测试之前,弄清被测试对象的职责,然后针对被测试对象的职责进行测试,单元测试写起来,真的不难。

How SSH works?

简介:

SSH,全名secure shell,其目的是用来从终端与远程机器交互,SSH设计之处初,遵循了如下原则:

  • 机器之间通讯的内容必须经过加密。
  • 加密过程中,通过 public key加密,private 解密。

密钥:

SSH通讯的双方各自持有一个公钥私钥对,公钥对对方是可见的,私钥仅持有者可见,你可以通过”ssh-keygen”生成自己的公私钥,默认情况下,公私钥的存放路径如下:

  • 公钥:$HOME/.ssh/id_rsa.pub
  • 私钥:$HOME/.ssh/id_rsa

通讯原理:

前提条件:

  1. 两个节点都持有各自的公钥私钥对,分别标记为PUBLIC KEY(client), PRIVATE KEY(client), PUBLIC KEY(server), PRIVATE KEY(server)
  2. 服务器上运行了SSH服务程序

建立通信通道的步骤如下:

  1. 客户端发起请求给服务器,服务器发回自己的public key给客户端
  2. 客户端检查这个public key是否在自己的$HOME/.ssh/known_hosts中,如果没有,客户端会提示是否要把这个public key加入到known_hosts中。
  3. 客户端会提示输入密码,用户输入密码后,客户端会使用PUBLIC KEY(server)对密码加密,然后发送给服务器。
  4. 服务器收到密码后,使用PRIVATE KEY(server) 解密,校验密码正确性. ??? 需要解密吗?
  5. 客户端把PUBLIC KEY(client), 发送给服务器。
  6. 至此,通讯通道建立完毕,当客户端想服务器发送消息时,会使用PUBLIC KEY(server)加密,服务器会使用PRIVATE KEY(server)解密,当服务器向客户端发送消息时,会使用PUBLIC KEY(client)加密,客户端收到数据后,会使用PRIVATE KEY(client)解密。

免密码登录:

我们的目标是: 用户已经在主机A上登录为a用户,现在需要以不输入密码的方式以用户b登录到主机B上。
步骤如下:

  1. 以用户a登录到主机A上,生成一对公私钥。
  2. 把主机A的公钥复制到主机B的authorized_keys中,可能需要输入b@B的密码。

    ssh-copy-id -i ~/.ssh/id_dsa.pub b@B

  3. 在a@A上以免密码方式登录到b@B
ssh b@B

SSH forwarding:

ssh -f user@ssh_host -L 1433:target_server:1433 -N

Getting started with chef

Set up a ubuntu node and run recipe on it

Predication:

  1. a running ubuntu node which accessiable via SSH from your labtop(workstation)
  2. cd to chef-repo directory.

    Steps:


    Bootstrap ububtu:
knife bootstrap IP_ADDRESS -x USERNAME -P PASSWORD --sudo


Verify the installation completed
knife client list

you will see your nodename in the client list

Download cookbooks from community site
knife cookbook site install getting-started

the cookbook named “getting-started” will be downloaded into chef-repo/cookbooks/

Upload the recipe to Hosted Chef so it is available for our nodes
knife cookbook upload getting-started 


Add this new recipe to the new nodes run list
knife node run_list add NODENAME 'recipe[getting-started]'


Run the added recipe remotely via ssh
knife ssh name:NODENAME -x USERNAME -P PASSWORD "sudo chef-client" -a ipaddress


Runnig chef-client as a deamon
knife cookbook site install chef-client
knife cookbook upload chef-client
knife node run_list add NODENAME 'recipe[chef-client]'
knife ssh name:NODENAME -x USERNAME -P PASSWORD "sudo chef-client" -a ipaddress


Advanced tips:

  • add recipe when bootstrap node
knife bootstrap IP_ADDRESS -r 'recipe[chef-client]' -x USERNAME -P PASSWORD --sudo