最重要的几点：
* 开始实践
* 如果某个问题难度太大：暂时保留下来，之后再回过头来重构代码
下面的情况说明你已经熟练起来了：
* 一天8小时已经能写出很多个测试了
* 能重构4个较长的函数或者类，并让它们通过测试
* 很不喜欢收到跳过测试的建议
* 已经快一周没用过调试器了
下面的情况说明你已经非常精通了：
* 能教会他人如何熟悉TDD
* 你的团队项目有很高的代覆盖率了（高于80%），并且还在持续提升
* 团队的技术负债在每一轮冲刺中不断降低
开发者要熟练掌握TDD，必须得经历的那些事情：
先编写测试代码，再写产品代码。之后，你的大脑会形成条件化的思维，也就是形成一个新习惯。40/4挑战是一种培养新习惯的方法。它的意思是在4周的时间段里，写出40个单元测试。之后，你会在TDD上取得突破，并变得熟练。你在代码编写中会遇到好些困难，并发现困难通常都能通过先进行微测试来解决。你会发现一两个自己难以解决的问题，但没关系，继续努力。4周过后再来重新解决这个问题， 这时候你已经成为了专家，能用你条件化的思维来平衡测试与产品代码了。在回顾微测试提供的快速反馈时，你感到非常享受。你开始注意到你开发出了更多的功能，而且在修复有问题的代码上花费的时间越来越少。
开发者熟练不起来的常见原因有哪些？
14到22集的IT戏剧《敏捷思维》中，我们列出了几个原因。毫无疑问，最常见的原因，就是开发者对于已有的思维定式太过于习惯和舒适了。“我不先写代码，就没法写出微测试来。”这种思维定式让他们不愿意战胜自己来尝试新事物。然后，不舒适的感觉让他们继续自己既有的固定思维，跳过了要先写的微测试，直接编写代码。但这样反而让通过测试和实现功能的周期更长，也更冒险，因为你老是会遇到问题却没有任何头绪。
下一集会讲述一种“调皮或优雅”的方式来计算团队速度，由敏捷教练Brandon Linton带给大家。
