《敏 捷 教 练：如何打造优秀的敏捷团队》—10.3 保持使用TDD

10.3  保持使用TDD

到目前为止，我们一直都在讲如何引入TDD和CI。然而，等团队把这些实践都用起来之后，你还需要继续辅助他们保持使用这些方法。如果团队已有自信可以用好TDD，你还能做些什么帮助他们继续提高呢？

留意运行缓慢的测试。下面这个故事要讲的是，一个团队为他们的测试感到非常自豪，结果却被运行缓慢的测试给拖了后腿。鼓励团队在改进构建脚本和基础设施时把时间因素考虑进去，以免发生这种情况。

运行缓慢测试的影响
Liz

我曾与某个团队合作，他们的自动化接收测试套件非常全面，然而运行这个完整测试套件需要整整两个小时。这意味着，开发人员等不及全部测试运行结束就已经签入了他们的工作成果，而这些代码经常都会破坏测试。等两个小时之后，他们知道了结果，其间提交代码的开发人员又多了几个，而且其每一个人都觉得是别人破坏了测试套件。结果就是，测试总是失败。

团队没有想过要把通过接收测试也当作完成用户故事的一部分，或是当作其“完成”的定义的一部分。随着时间流逝，代码库的质量越来越差，通不过的测试变得越来越多。总是通不过的接收测试没有附加任何价值。

作为教练，我鼓励开发人员给测试套件提速，在接收测试失败时停止增加代码。可是，项目压力实在太大了，开发人员觉得他们需要专注于实现更多故事。

终于在某天，情况实在太糟糕，必须采取行动才行。于是，一些开发人员开始修复失败的测试，而团队其他人则协助QA团队一起测试产品。除非现有测试全部通过，否则所有人都不许增加新功能。

测试当天即被修复。但测试套件仍然运行得很慢，于是第二天测试又失败了。而且它们在项目剩余时间内一直都是通不过的状态。为了做到如期交付，偷工减料也越来越多。随着最终期限的临近，已经没人知道团队距离“完成”还有多远。经历恐怖的测试阶段之后，他们最终还是完成了发布，而那正是他们原本希望通过自动化测试所避免的。

如果缓慢的测试并不多，可以把运行时间长的测试隔离成单独的测试套件在后台运行。如果运行缓慢的测试有很多，可能得归咎于其过于依赖外部资源的粗劣设计。团队需要多写一些使用测试替身的测试，例如模拟对象或桩(stub)，通过它们屏蔽掉那些外部资源。还有一个解决方案，把测试拆开来放进构建农场[1](build farm)运行。

团队需要大量支持和鼓励，方可真正做到用测试来驱动开发。要提防开发人员借口“只改区区一行”而不写测试的情况。因为只改一行而不写测试这种事情，做太多就会变成不给遗留代码写测试的借口。

协助他们把测试覆盖率变得更明显。其增速应该和代码增速基本持平。度量工作可以用代码覆盖率分析工具来完成。但别忘了，这些工具只检查测试是否运行了所有代码而已，他们无法检测这些测试的优良程度。保持警惕，杜绝低劣测试拼凑覆盖率的情况。

让成功测试可见
Liz

我曾合作过某个团队，他们刚接触TDD。我会在团队板上清楚地写下成功测试和失败测试的数目。我们会在每日站会时检查这些数字，判断团队做得有多好。这帮助他们把测试放在了心上。

我只坚持了个把月，团队就已经完全掌握了TDD，也记住了要确保所有测试都能通过。

那么，如果团队已经有了良好的测试覆盖率和快速运行的测试，还能做些什么呢？也许是时候修订测试策略了。鼓励他们扩大自己的覆盖面，寻找架构中没有测试的新领域。