Kent Beck  是《解析极限编程》和《测试驱动开发》的作者，他认为软件开发就如同高尔夫一样，是一项长期和短期相结合的运动。JUnit是适合于长期运动项目的例子——大量的用户，稳定的收入（如果收入不幸是分文无有的话，对所有参与者都是可悲的），其关键目标是要保证开发领先于使用者的需要。

　　“当我开始实现JUnit Max时，才逐渐明白规则已经发生了变化。最要命的问题曾经是（现在也是）：“哪些功能可以吸引付费客户？”从定义来看，这是一个无解的问题。如果JUnit（或任何其他免费软件）实现了一个同样的功能，没有人会为Max付费。

　　JUnit Max的成功之处在于它开始赢利并不断扩大收入：付费用户越来越多，每个用户所带来的收入越来越多，病毒传播系数【译者注】也越来越高。从定义来看，既然取得成功的方式不为人知，那就进行大量实验，并结合实际使用得到的反馈，这就可以使得成功的机率最大化。”

　　JUnit Max将所有内部错误报告到一台中央服务器，一旦问题出现，Kent就立即可以获悉。这种错误日志可以帮助找出两个问题。对于第一个问题，他可以写一个简单的测试使之重现，并验证相应的修补程序。第二个问题解决起来很容易，但Kent预计需要几个小时才能为它写出一个测试。在这样的情况下，他就直接修复问题并交付了。

　　Kent接着说：

　　“当我开始实现Max时，在第一个月里没有做任何自动化测试，所有的测试都是我手动做的。有了最初几个付费用户后，我才回头为已有的功能写测试。并且，我认为这种工作次序让我在单位时间内可以验证的实验数量最多。只用少许或根本不写代码、不写测试，这让我可以更快地开始（我花了近一周的时间才写完第一个测试）。一旦前面的代码被证明是有价值的（就这个项目来说，我的一些朋友愿意为它付费），这种测试就能让我能更有信心地快速完成实验。

　　是否进行自动化测试，需要对一系列因素进行权衡。即使在Max项目中我也写了不少的测试。如果我能找到一种简单的方式写测试，我就会先为所有功能开发验收测试。尤其是在我不能确定某个功能该如何实现时，写测试会给我很好的想法。在Max项目中，是否写测试这个问题发生了变化，变成了测试能否有助于我在单位时间内验证更多实验。如果有帮助，那我就写测试。如果没有就不写，甭管有啥危险。我正在力图通过Max获得更多收入。要论证围绕设计所付出的努力，这个过程同样复杂，只不过那是下一篇文章要讨论的话题了。”

　　Ron Jeffries是《极限编程实施》的作者，他回应说：“我相信你，此外还包括三个人，你们能在短期项目中做出正确决策。多年来的经验告诉我：在针对短期项目的决策影响曲线中有一个拐点，项目的可靠性和开发进度会从该点急剧下降。

　　Johannes Link是敏捷软件教练 ，他说：“我看到有那么几个开发人员能够作出合理的短期或长期决定，但还没见到过能做到这一点的团队，更不用说一个组织了。”

　　Michael O'Brien则给出了不同的评论：“在我看来，这是出色的文章，他也作出了正确的决定。我们在写代码时常常陷于追求漂亮和一致，而忘记了写代码的目的 。我写测试，是因为这可以让我写起代码来更容易，而且让我确信代码按我预想的方式工作。如果写测试不能帮我达到上面的目的，我会说：跳过它。”

　　Olof Bjarnason认为：“Kent提出了反馈流的概念。如果我们着眼于让单位时间内的反馈流多起来，那就走对方向了。例如，他提到在JUnitMax这个短期项目中，他发布的功能都没有经过测试，这样在项目一开始就可以带来最多反馈流，其原因在于编写第一个测试太困难了，竟用了他一个多星期时间。他通过频繁地修改和发布获得了很高的反馈流。他的‘红色测试’是由早期的少数用户和他们的反馈意见构成。”

　　Guilherme Chapiewski有这样的顾虑：在很多情况下人们会误认为某些项目是短期项目。Guilherme遇到的情况是：之前为了验证某个想法，他打算开发一个没有任何测试的小项目。项目完成后人们开始使用它，很快就找到一些无法修复的bug。最后，他得出结论:代码写得太烂，根本无法测试。他只得扔掉已有代码，再从头来过。

　　Kent对许多评论做出了回复：“我同意，实践和原则的混乱会导致问题。测试会产生更好的设计。这就是为什么我有大概30个功能测试和25个单元测试（奇怪的平衡吧，这是由于Eclipse应用很难进行测试）。几乎所有的新功能我都先加了验收测试。这样做减少了整个周期耗费的时间。”

　　这个想法能安全应用到不止一、两个人的团队中吗？除了Kent Beck，人们是否有能力去判断该不该采用这种方式呢？

　　译者注：病毒传播系数，英文名为viral coefficient，用来度量每个已有用户带来的新用户数，与“病毒营销（viral marketing）”相关。