本文是对Cedric发贴的回复
一些赞成
Cedric提出了一些不错的观点，尤其是指出了如果敏捷开发的“传道士们”只使用教条的论点，而不去接触那些遇到实际的问题的真实的开发者，那么他们就没法再将敏捷进行到底。早期的接受者已经采纳了；而下一代是比较摇摆不定的，想影响他们我们就必须用更强的与现实开发紧密相连的论点。
然而，我非常不赞成Cedric所提的关于“风险的考量”的观点。从我的观点来看，发布那些你不确定能运行的代码是完全不可取的。要么确信发布的能运行，要么就不发布。在这一过程中，有足够的风险要去处理。
风险的考量@H_301_31@@H_301_31@
此外，没人能真正的做到风险的考量，他们真正能做到的是去希望。他们希望他们的代码能工作得足够好，使得客户和经理们都不会为之发脾气。坦白的讲，正是这种抱有希望的态度才让软件工程师看起来像是个傻瓜。我们乐观地发布了软件的最新版本，然后手指交叉于背后，祈祷客户不会做那些会让系统崩溃或是数据库毁坏的事。
一个会崩溃的功能远比那些未实现的功能要糟糕的多。一个未实现的功能会使发版延期而且可能会给竞争对手带来优势，可是一个会崩溃的功能却让我们的客户变成敌人。客户像我们所承诺的那样使用着这些功能。当我们发布了一个功能，那是在承诺它是可以运行的；当它崩溃了，我们就破坏了曾经许下的承诺；如果破坏了太多的承诺我们就失去了信任。
栈、对列、保龄球和FitNesse程序@H_301_31@（译注1）
Cedric抱怨的所有有关TDD（译注3）@H_301_31@的例子都是些不重要的小事，像是栈、对列、和那些保龄球游戏程序。你有理由去怀疑这样简单的例子，因为它们不是真实的。但这样简单的例子的存在也是有理由的，那是因为它们与当时环境吻合。所以这是个老问题，而且Cedrick也不是第一个提出它的人了，它是在35年前的那场无休止的关于结构化编程的争论中被提出的。
然而，Cedric对于没有重要例子的观点是错误的，我想为Cedric介绍一下FitNesse程序。它有30,000行Java代码，先写的测试，而且测试的代码覆盖率（译注4）@H_301_31@达到90%以上。我非常建议他去学习学习FitNesse程序@H_301_31@，这既是个正面的例子，也有的反面的。FitNesse是一个拥有真实客户和真实问题的真实应用程序，它是一个web驱动的程序，有后台数据库和一些相当复杂的业务规则，而且涉及多个独立进程和多种语言。
测试不是程序行为的描述
当然测试是，它是程序行为的清晰描述。我也同意测试不能说明所有事情，power-function就是个可以说明的例子（虽然我很想问问Cedric他拿什么来确保它的软件是能工作的）。@H_301_31@你不能用测试来描述所有东西，但你却可以描述很多。实际上，你可以通过编写测试来做到描述系统的绝大多数重要的行为。@H_301_31@@H_301_31@
@H_301_31@@H_301_31@这可不是什么新花样，帕纳斯表就是一个能用测试来清晰描述的例子，决策表也是一个。实际上，软件行为最好可测试，否则系统的测试就会无章可循。@H_301_31@@H_301_31@
Cedric认为你无法依赖于测试去描述你的系统，这是对的，但他关于通过测试来描述系统的原则是错的。除了编写测试并使之通过，几乎没有比这更清晰、通用的方法了。@H_301_31@@H_301_31@
任何不能测试的都是无用的
如果你不能测试它，你就不知道它能运行。如果你不知道它能运行，它就是没用的。如果你有一个需求，可是无法证明你能实现它，那这就不是一个需求。
但你可以测试@H_301_31@@H_301_31@
计算机的任何行为都是可测试的。而且，对于任何运行于有限内存中的计算机程序，你都能用有限的测试（具体数目可能会很大）来证明它是能够按照预期工作的（就算是power function）。因此，最终描述一个程序行为的是能够示意其行为的完完整整的一系列测试。@H_301_31@@H_301_31@当然，每人能测试那么多（覆盖程序全部行为），所以我们选用统计手段。我们选择代码覆盖而不是路径覆盖（译注5）@H_301_31@；@H_301_31@我们确保每一行代码都能在测试中执行到；我们确保每一个程序分支都被测试到；如果我们测试过每一行代码，每一个程序分支，这个系统就能按照预期所描述的工作，而且，我们就实现了风险的考量（在此情况下确实如此）。我们称此为“一份耕耘，一份收获”。@H_301_31@@H_301_31@
Cedric所谈论的“风险的考量”，他可能是在说一种在比上述所谈更初级的阶段。如果一个开发团队，他们花了足够的努力在测试上，而且做到了让所有代码行和程序分支都被覆盖到了一个很高的层级，而且他们清楚这样的覆盖层级上，程序的缺陷密度会被控制在一个足够低的级别中，那么他们就算是做到了风险的考量，那是因为一份耕耘，一份收获。
进而，我们就不会再讲像是“我上周在笔记本上运行过，看起来能正常工作啊。”的话了。@H_301_31@@H_301_31@
敏捷人是认同它的
其实，敏捷人是认同它的。我们非常的认同，而且我们一直以来都在帮助这个行业的其它人也接受它。现在，几乎公司无论大、小，几乎都至少用过敏捷开发方法的一、两种。还有很多很多在此技术上下了很大的功夫，而且他们现在正在享受着敏捷所带来的好处。
敏捷不是银弹；敏捷也不是答案。但是敏捷技术，尤其是TDD，是能够确保软件写好的强大技术，而且也是确保整个行业的专业水平得到提升的强大技术。@H_301_31@@H_301_31@
@H_466_502@译者注：Robert C. Martin是Object Mentor公司总裁，面向对象设计、模式、UML、敏捷方法学和极限编程领域内的资深顾问。他不仅是Jolt获奖图书《敏捷软件开发：原则、模式与实践》（中文版）（《敏捷软件开发》（英文影印版））的作者，还是畅销书Designing Object-Oriented C++ Applications Using the Booch Method的作者。Martin是Pattern Languages of Program Design 3和More C++ Gems的主编，并与James Newkirk合著了XP in Practice。他是国际程序员大会上著名的发言人，并在C++ Report杂志担任过4年的编辑。@H_301_31@
原文链接：https://www.f2er.com/javaschema/288315.html