本文是对Cedric发贴的回复

一些赞成

Cedric提出了一些不错的观点，尤其是指出了如果敏捷开发的“传道士们”只使用教条的论点，而不去接触那些遇到实际的问题的真实的开发者，那么他们就没法再将敏捷进行到底。早期的接受者已经采纳了；而下一代是比较摇摆不定的，想影响他们我们就必须用更强的与现实开发紧密相连的论点。

然而，我非常不赞成Cedric所提的关于“风险的考量”的观点。从我的观点来看，发布那些你不确定能运行的代码是完全不可取的。要么确信发布的能运行，要么就不发布。在这一过程中，有足够的风险要去处理。

风险的考量

此外，没人能真正的做到风险的考量，他们真正能做到的是去希望。他们希望他们的代码能工作得足够好，使得客户和经理们都不会为之发脾气。坦白的讲，正是这种抱有希望的态度才让软件工程师看起来像是个傻瓜。我们乐观地发布了软件的最新版本，然后手指交叉于背后，祈祷客户不会做那些会让系统崩溃或是数据库毁坏的事。

一个会崩溃的功能远比那些未实现的功能要糟糕的多。一个未实现的功能会使发版延期而且可能会给竞争对手带来优势，可是一个会崩溃的功能却让我们的客户变成敌人。客户像我们所承诺的那样使用着这些功能。当我们发布了一个功能，那是在承诺它是可以运行的；当它崩溃了，我们就破坏了曾经许下的承诺；如果破坏了太多的承诺我们就失去了信任。

栈、对列、保龄球和FitNesse程序（译注1）

Cedric抱怨的所有有关TDD（译注3）的例子都是些不重要的小事，像是栈、对列、和那些保龄球游戏程序。你有理由去怀疑这样简单的例子，因为它们不是真实的。但这样简单的例子的存在也是有理由的，那是因为它们与当时环境吻合。所以这是个老问题，而且Cedrick也不是第一个提出它的人了，它是在35年前的那场无休止的关于结构化编程的争论中被提出的。

然而，Cedric对于没有重要例子的观点是错误的，我想为Cedric介绍一下FitNesse程序。它有30,000行Java代码，先写的测试，而且测试的代码覆盖率（译注4）达到90%以上。我非常建议他去学习学习FitNesse程序，这既是个正面的例子，也有的反面的。FitNesse是一个拥有真实客户和真实问题的真实应用程序，它是一个web驱动的程序，有后台数据库和一些相当复杂的业务规则，而且涉及多个独立进程和多种语言。

测试不是程序行为的描述

当然测试是，它是程序行为的清晰描述。我也同意测试不能说明所有事情，power-function就是个可以说明的例子（虽然我很想问问Cedric他拿什么来确保它的软件是能工作的）。你不能用测试来描述所有东西，但你却可以描述很多。实际上，你可以通过编写测试来做到描述系统的绝大多数重要的行为。

这可不是什么新花样，帕纳斯表就是一个能用测试来清晰描述的例子，决策表也是一个。实际上，软件行为最好可测试，否则系统的测试就会无章可循。

Cedric认为你无法依赖于测试去描述你的系统，这是对的，但他关于通过测试来描述系统的原则是错的。除了编写测试并使之通过，几乎没有比这更清晰、通用的方法了。

任何不能测试的都是无用的

如果你不能测试它，你就不知道它能运行。如果你不知道它能运行，它就是没用的。如果你有一个需求，可是无法证明你能实现它，那这就不是一个需求。

但你可以测试

计算机的任何行为都是可测试的。而且，对于任何运行于有限内存中的计算机程序，你都能用有限的测试（具体数目可能会很大）来证明它是能够按照预期工作的（就算是power function）。因此，最终描述一个程序行为的是能够示意其行为的完完整整的一系列测试。当然，每人能测试那么多（覆盖程序全部行为），所以我们选用统计手段。我们选择代码覆盖而不是路径覆盖（译注5）；我们确保每一行代码都能在测试中执行到；我们确保每一个程序分支都被测试到；如果我们测试过每一行代码，每一个程序分支，这个系统就能按照预期所描述的工作，而且，我们就实现了风险的考量（在此情况下确实如此）。我们称此为“一份耕耘，一份收获”。

Cedric所谈论的“风险的考量”，他可能是在说一种在比上述所谈更初级的阶段。如果一个开发团队，他们花了足够的努力在测试上，而且做到了让所有代码行和程序分支都被覆盖到了一个很高的层级，而且他们清楚这样的覆盖层级上，程序的缺陷密度会被控制在一个足够低的级别中，那么他们就算是做到了风险的考量，那是因为一份耕耘，一份收获。
进而，我们就不会再讲像是“我上周在笔记本上运行过，看起来能正常工作啊。”的话了。

敏捷人是认同它的

其实，敏捷人是认同它的。我们非常的认同，而且我们一直以来都在帮助这个行业的其它人也接受它。现在，几乎公司无论大、小，几乎都至少用过敏捷开发方法的一、两种。还有很多很多在此技术上下了很大的功夫，而且他们现在正在享受着敏捷所带来的好处。
敏捷不是银弹；敏捷也不是答案。但是敏捷技术，尤其是TDD，是能够确保软件写好的强大技术，而且也是确保整个行业的专业水平得到提升的强大技术。

译注：

1，Fitnesse，一个知名的验收性测试（译注2）框架，Object Mentor公司开发。

2，验收性测试，又成为容忍测试，敏捷方法认为，如果一个构建（build）通过了验收测试，基本上这个构建就可被“接受了”。

3，TDD，测试驱动开发，一种典型的敏捷开发方法，详情可见相关文章。

4，代码覆盖，code coverage，实际上作者此处是指白盒测试中的语句覆盖和分支覆盖，即statement coverage和branch coverage。语句覆盖是最起码的结构覆盖的要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。分支覆盖，又称判定覆盖，它要求设计足够多的测试用例，使得程序中每个判定之少有一次为真值，有一次为假值，即程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!