ATDD实战

AlexQin · 发表于 2015-5-2 11:35

步骤3 执行验收测试，但是会失败

按照测试三角，下一步要运行测试，但是会失败。

同样，我使用Eclipse快捷键来创建缺失方法的空白版本。很好！运行测试，看，出现了红色！

AlexQin · 发表于 2015-5-2 11:36

步骤4：将验收测试变为绿色

现在，我需要编写一些生产级别的代码。我为系统添加一些新的概念，有一些所添加的代码并不是试验性的，因此需要进行单元测试。我使用了TDD的方式，它与ATDD类似，但是范围更小一些。

以下展现了ATDD和TDD如何组合在一起。可以将ATDD视为外部的循环：

对于每个验收测试循环（在特性级别）的回路中，我们都会有很多单元测试的回路（在类和方法级别）。

所以，尽管我在较高的层次上关注于将验收测试变为绿色（这可能会耗费几个小时的时间），但是在较低的层次上我可能会关注于将下一个单元测试变为红色（这可能只会耗费几分钟的时间）。

这并不是非常严格的TDD（Leather & Whip TDD）。这更像是“至少要保证单元测试与生产级别的代码是同时提交的”。这种提交每小时会发生多次，大致就可以将其称之为TDD了。

AlexQin · 发表于 2015-5-2 11:37

步骤5：清理代码

像通常那样，在验收测试变成绿色之后，就要进行清理工作了。不要试图越过这个步骤！就像在饭后清洗餐具一样——需要马上去做。

我不仅清理了生产环境中的代码，还清理了测试代码。例如，我将凌乱的try-catch部分抽取到一个帮助方法之中，从而最终实现了漂亮且整洁的测试方法：

@Test
public void passwordProtect() {
myClient.createNewWhiteboard();
String whiteboardId = myClient.getCurrentWhiteboardId();
myClient.protectWhiteboard("bigsecret");
assertCantOpenWhiteboard(joesClient, whiteboardId);
assertCantOpenWhiteboard(joesClient, whiteboardId, "wildguess");
joesClient.openProtectedWhiteboard(whiteboardId, "bigsecret");
assertTrue(joesClient.hasWhiteboard());
}

复制代码

我的目标是让验收测试尽可能简短、整洁并且易于使用，以至于注释都是多余的。最初的伪代码或注释会作为模板——“我希望代码就是如此得简洁！”。移除注释会给我一种成就感，它的一个积极作用就是让方法更加简短了。

AlexQin · 发表于 2015-5-2 11:37

下一步做什么？

重复地进行净化。在第一个测试用例通过之后，我就要开始思考缺失了什么。例如，密码保护应该还需要用户认证。所以，我为此添加一个测试、使其变红色、再变成绿色然后进行清理。诸如此类。

以下就是我（到目前为止）为该特性所添加的完整的测试：

passwordProtectionRequiresAuthentication()
protectWhiteboard
passwordOwnerDoesntHaveToKnowThePassword
changePassword
removePassword
whiteboardPasswordCanOnlyBeChangedByThePersonWhoSetIt

当发现缺陷或添加新特性时，我稍后肯定会添加新的测试。

我总共用了大约两天的时间进行高效地编码。在这个过程中，有很大一部分是回过头去重新编码和设计，并不像本文所展示那样线性进行。

AlexQin · 发表于 2015-5-2 11:38

那手工测试呢？

在自动化测试变成绿色后，我也会进行很多的手工测试。但鉴于自动化测试已经覆盖了基本的功能和很多边界场景，因此手工测试可以更多地关注主观性和探查性的内容。高水平的用户体验是什么样的？流程合理吗？它易于理解吗？我需要在什么地方添加帮助文本？按照美学，设计是否可接受？我不想去争取什么设计大奖，但我也不想让它很丑陋。

强大的验收测试能够让我们不必再进行单调且重复性的手工测试（也被称为“搞怪测试monkey testing”），进而节省出时间来进行更有意思和更有价值的手工测试。

理想情况下，我应该在开始阶段就构建验收测试，所以一定程度上来讲这种方式是在偿还技术债。

AlexQin · 发表于 2015-5-2 11:38

关键点

就这样，我希望这个样例对你有用！它阐述了一种典型的场景——“我要实现新的特性，最好要编写验收测试，但是到目前为止还没有这样的测试，我不知道该使用什么框架，甚至不知道该如何开始”。

我非常喜欢这种模式，借助这种方式我多次走出了困境。总结如下：

在便利的帮助类（在我的场景中也就是AcceptanceTestClient）背后假设封装了复杂的框架。
为已经可以运行的特性编写非常简单的验收测试（如只是打开应用）。使用它来驱动你的AcceptanceTestClient实现以及相关的测试配置（如假的数据库连接和其他外部服务）。
为新的特性编写验收测试。运行它，但是会失败。
使其变成绿色。在编码的过程中，对所有非试验性的内容编写单元测试。
重构。可能会额外编写更多的单元测试或移除多余的测试。保持代码的整洁！

完成这些后，你就已经越过了最困难的门槛，已经开始了ATDD！

AlexQin · 发表于 2015-5-2 11:39

关于作者

Henrik Kniberg是斯德哥尔摩Crisp的敏捷/精益教练，主要的工作内容是Spotify。他很乐意帮助公司在软件开发的技术和人力方面取得成功，就像他的图书“Scrum and XP from the Trenches”（本书中文版书名为《硝烟中的Scrum与XP》）、“Kanban and Scrum, making the most of both”以及“Lean from the Trenches”（本书中文版书名为《精益开发实战：用看板管理大型项目》）所描写的那样。

原文英文链接：ATDD From the Trenches

[转载] ATDD实战

浏览过的版块