ATDD实战

ATDD实战2014-06-09 infoq/Henrik Kniberg 译：张卫滨验收测试驱动开发入门

你是否遇到过这样的场景：

那么本文就是为您而作——以一个具体的例子阐述了如何基于已有的代码库启用验收测试驱动开发（acceptance-test driven development）。这是应对技术债解决方案的一部分。

这是带有一定缺陷的现实世界的样例，并不像教科书中的样例那样完美。所以完全是来自于实战。我只会使用Java与Junit，而没有使用其他的第三方测试框架（这些框架基本上已经被过度使用了）。

免责声明：我并不是说这就是正确地方式，关于ATDD有很多其他的“偏好（flavors）” 。同时，本文中也没有太多新鲜的或革新性的内容，它只是一些确定的实践以及通过辛苦得来的经验。

我想做什么

几天前，我开始为webwhiteboard.com（我的小项目）添加密码保护的特性。很久以来，人们就希望有一种密码保护在线白板的方式，现在该实现这个功能了。

听起来这是一个很简单的特性，但是需要做很多的设计决策。到目前为止， webwhiteboard.com是基于匿名使用的，没有任何的账户、登录或密码这样的东西。什么人能够保护白板呢？谁能访问它呢？如果我忘记密码该怎么办？我们如何在足够安全的同时保证尽可能简单？

webwhiteboard的代码库有着很棒的单元测试和集成测试的覆盖率。但是它并没有验收测试，也就是站在用户的角度进行端对端流程的测试。

设计要素

webwhiteboard的主要设计目标是很简单的：尽可能简化登录、账户以及其他繁琐事情的需求。所以我为密码特性建立了两个设计限制：

对白板设置密码需要用户认证，但是访问密码保护的白板并不需要。也就是说，用户访问保护的白板需要输入密码，而不需要“登录”。

登录会使用第三方的OpenId/Oauth服务提供商，最初会使用Google。按照这种方式，用户就不需要再创建账号了。