这个故事的意义就在于它是比较早的拥护“测试先行”编程方式的实例——在实现某个功能之前先把测试写出来，而不是只在计划或者口头说说。另外，这个故事也说明了如何把短期、临时性或针对性代码转变为长期、稳定的方案。
不过对于我们而言，最重要的是帮助证实测试将降低效率这一谬论。这里所说不是代码编写人员的效率——而是用户的效率。或者更广泛地说，是这个开发链下一个环节的人的效率。
所谓测试会“降低效率与浪费时间”，充其量也只是针对编程人员而言。而所有可能出现的问题则会堆积起来，直到下一个环节才被放大，浪费更多的时间和效率。当然，程序员可以继续解决任何后面出现的问题，不过你还会认为这属于“正常工作”范畴内吗?如果人们无法把编写单元测试看作他们正常工作的一部分，他们就可能把它当作是对正常工作的一种巨大干扰，而不是考虑如何在工作中取得一个和谐的平衡点。
解决应该解决的问题
许多局部优化实际上是对全局的掌握不够，因为他们无法意识到更深层次的问题。这样，他们所做的许多解决性措施就只能解决表面问题，而无法触及问题的根本所在。如果迭代过于频繁而无法进行单元测试，这就意味着迭代的频率已经超出了这个团队或机构的产能。这个产能当然包括团队的单元测试能力。
小周期迭代的目的并不是在短时间内进行迭代，迭代的目标是减少风险，以及通过持续发布功能性完整的增量版本来提高价值、改善工作流程。如果有达不到要求的地方，那么很可能是系统中的某一部分限制了迭代频率。如果无法解除这个限制，那么最好还是延长迭代的周期，使其更适合当前的环境，而不要“赌气”似的强制使用这个周期。
被动式的回归测试
为什么有人说回归测试比单元测试更有效呢?虽然具体还要取决于回归测试指的是什么，不过这也暗示了他们对回归测试作用的误解。
通过再运行一次同样的测试，回归测试保证了对代码所做的任何改动并没有影响到先前测试过的行为。但是新功能呢?按照定义，你不能用回归测试确定新功能的行为或者新功能可以实现预期的行为。所以关键就是要明白“回归”这个词。
回归测试并不是一种仅仅与单元测试不同粒度的测试，它表示的是一种预期的测试结果。回归测试可以在单元、系统或者之间的任何层次上进行。它的意义在于保证不应改变的部分没有被改变。而新测试则是要保证发生改变的部分已经根据预期产生了相应的效果。
文章来源于领测软件测试网 https://www.ltesting.net/
