第二个故事：聊聊天找问题

　　用户希望我们的系统可以定期清理过于老旧的数据，在清理前可以发信给用户进行确认。我们需要实现的功能如下：1可以配置是否打开提醒；2可以配置提醒后是否删除，即只提醒但不自动删除。在与开发人员T坐下来一起编写Feature时，此功能的代码已经实现了一大半。

　　我的第一个Feature如下：

　　Given 用户有一个老旧数据

　　When 管理员打开此功能

　　Then 用户收到提醒邮件，内容包括：你的旧数据不久会被删除

　　And 不久后，数据被删除

　　Given 用户有一个老旧数据

　　When 管理员打开此功能，但是屏蔽了自动删除

　　Then 用户收到提醒后见，内容包括：你有一份旧数据

　　And 不久后，数据未被删除

　　写到这里，T一拍大腿，说糟了，我只写了一份邮件模板。不管管理员是否开启自动删除，都会告诉用户，旧数据即将被删除。听到这里，你也许会纳闷，这种问题怎么会留到此时才被发现，这同我们组的开发模式有关，我笑称我组的开发模式为迅雷模式，有空我会写一篇模式分析，来专门讨论一下这个手工作坊式的开发模式。这里我想说的是，只有当你和开发人员坐下来，具体地讨论到每一个细节，才能帮助开发人员尽早发现这些问题。

　　第三个故事：培养可测试性

　　接着第二个故事向下说，我注意到此功能里涉及到了用户会接受邮件的这个功能。因为我们的测试环境在单独的网络拓朴里，而那个环境里我们并没有搭建电子邮件服务器，所以接受/发送电子邮件的功能，我们都是等到做系统测试（system testing）才进行的。因为代码尚在开发期，所以我跟T商量，说咱们怎么能不出内网能知道你有发信呢。

　　解决办法有两个，1，做一个发信的Mock，让产品调用，然后把被调用的信息发送给我的测试系统；2，把发信内容打印到调试的日志里。我们选择了2，简单直接。

　　从这个例子，我俩意识到，在产品代码未提交前，只要加入可测试性的思考，可以把一个本来不太容易测试到的功能，通过一些小手段测试到。而这些小办法，小手段，有时甚至不需要增加额外开销，却可以极大的增加测试效率。

　　我的故事讲完了，虽说精简了很多技术细节，但每个故事都是真实的。每一个故事里，我都提到了开发人员，因为我确实是每一个功能点，都是在与开发人员的协同工作下完成的。

　　在结束前，依然要提一些BDD过程中遇到的问题。我依然很惋惜的见到有人孤军奋战，一个人埋头编写Feature描述。有时，这孤军是开发人员，觉得自己可以清楚地描述即将实现的功能；有时候，这孤军是测试人员，已经跟开发人员接触过，有能力独自完成任务。然而，当我去走查（Review）他们完成的Feature文件，一眼能看出，这不是一份经过深思熟虑的描述，其中包含了些含糊的步骤或过分简单的数据。

　　跟H聊天时，提到这个问题，他也一再告诫我：“如果BDD只对你一个人适用，那么它不是一个好方法。”第一步，Cucumber的使用，BDD的概念，已经成功的推广了。接下来，艰难的实施部分，如何改变组员单独作战，只重速度和数量，不重质量的习惯。以及如何让大家习惯于协同作战呢。