测试优先的原教旨主义像禁欲教育:是一个不切实际的、无效的道德活动，让人自我厌恶和羞耻。
　　刚开始时情况并非如此。当我第一次发现TDD，它像一个礼貌的邀请，一个能够更好地编写软件的世界。心灵上的促动使你去开始测试实践。它开阔了我的眼界，经过良好测试的代码库，他带来了软件变革的信心。
　　测试优先是很好的自我训练方式，它教我如何在更深层次上思考测试，除此之外也有些内容我很快抛之脑后了。
　　然而，多年来，关于测试优先的言论声音越来越大，而且常令人非常生气，甚至是卑鄙。有时我被卷入原教旨主义的漩涡，之后会因为没有跟随真正的福音而感觉不好。之后的几周时间我尽量尝试着测试优先。只有当它开始伤害我的设计时，我才再次停止它。
　　当我能够坚持的文字字母教义，我会感觉这是溜溜球循环的骄傲；当我没有做到时，我感觉陷入绝望的崩溃。这感觉像是跌落马车一样。有些事情需要保持沉默。当然不是在公共场合承认。在公共场合，我充其量只是提到不做测试优先，并在坏的情况下继续支持实践“正确的方式”。但我现在后悔了。
　　也许使用测试先行这种违反直觉的方式来改变缺少自动化的回归测试的行业现状，是有必要的。也许这只是一个寓言，只是一个没有文字描述准备的软件编写的日常运作。无论他以什么形式开始，很快堕落了。被人用做锤子用来
　　打倒不同意见，告诉他们是不专业的，并不适合编写软件。这是一个试金石。
　　足够了。没有更多了。我的名字是大卫，我不奉行测试有限。我拒绝为它的任何事道歉，更别说隐藏它了。我很感激TDD开拓了我自动化回归测试的眼界，但我早已跟从设计教条了。
　　我建议你认真看看何为这种方法做系统设计的完整性。如果你愿意认真考虑它的可能性，这不是一个不合格的好，像红色药片。你可能不喜欢你所看到的东西。
　　因此，我们该何去何从？
　　第一步是要承认一个问题。我认为我们现在已经看到了。第二步是从单位到系统重新平衡测试光谱。当前狂热的TDD经验导致主要集中在单元测试，因为这些都是测试驱动代码设计的能力(原测试优先的理由)。
　　我不认为这是个很健康的想法。测试优先单元会导致过度复杂的网络中介对象，为了避免做任何“慢”的事情，会导致间接行。像链接数据库，或文件IO。或者通过浏览器来测试整个系统。生成了一些真正可怕的怪物的建筑。如果服务对象是茂密的丛林，这种命令模式的话更糟了。
　　我很少进行那些所有依赖项都被模拟，成千上万的测试可以在几秒钟内完成的传统意义上单元测试，。我直接测试Rails的Active record，让它们直接访问数据库，然后在其上部防止一些控制器的测试，但我宁愿使用Capybara 更高水平的系统测试取代它们。
　　我认为这是我们前进的方向。不要太过重视单元测试，因为我们不再做测试优先设计实践，更强调的是，缓慢、系统测试。(顺便说一句，由于先进的并行化和云基础设施，我们不再需要如此缓慢地运行)。
　　Rails可以帮助这种转变。我们除了鼓励全系统测试外什么都不做。在堆栈里，并没有默认的答案。这是一个需要我们修复的错误。但你不必等到发生时才做。让 Capybara运行，你会有一个美好的明天。
　　但是，请首先深呼吸。我们现在正赶一些神圣的牛去屠宰。这是痛苦的和血腥的。TDD一直如此成功以致让很多程序员的身份交织在一起。TDD不仅仅是他们做什么，还要搞清楚他们是谁。我们前面，有一些严重的思想阻止我们摆脱困境，这将是需要一些时间的。
　　糟糕的事情是，我们能做的只是冲到另一个测试的宗教。我只可以想象 “只测试系统”的金牛犊!现在，请不要去那里。
　　是的，于我而言，测试优先已死。但是，与其说它是跳舞的坟墓，我宁愿纪念它所作出的贡献，而不是停留在悲剧哪里。这是我们历史上一个重要的阶段，但现在是时候继续前进了。
　　测试永存。