作为一个应届生，来到ThoughtWorks学到的第一件事就是TDD。在学校的时候，自动化测试是老师要求才会去补上的，更别提是测试提前，在接触之前，怎样实现根本是想象不到的。当时我的Buddy带着我在项目中一点一点的了解测试，实践TDD。后来去了，TWU，TDD也是很重要的一课，每一个方法的实现之前，一定是从测试开始的。
现在在我们项目上，我已经很熟悉TDD，也很熟悉有测试这样一个东西存在在项目中，每次我做一些修改的时候，我就会心跳加速，充满了恐慌。然后跑一遍测试，得到结果的那一刻，无论是否是success，我都像是吃了一颗定心丸，感到无比的安心。
偶然的某次机会，我跟曾经一同去TWU的小伙伴聊起了各自的项目，当我听到他们说起他们项目的单元测试跑一次要很久，有的几乎没有测试的时候，我想象了一下我坐在电脑前，做的每一次修改如果没有测试可以跑，我该有多么的恐慌。
在《代码整洁之道》中，Rober最常提到就是测试。他在重构的时候，每进行一点改变，就会跑一次测试，每次跑完测试都会让他可以安心的继续前行。在《持续集成》和《持续交付》中，提到在代码提交到pipeline的第一环同样也是跑测试。
在我刚入职不久的时候，偶然参加了一个编程活动，在一开始的时候，由于时间充裕，我写了一个测试用于保证得到我期望的结果。测试引导着我很快的就得到了正确的代码。但是第二个程序的时候，我突然就觉得时间紧迫，也是基于莫名其妙的自信，我没有写测试。之后我陷入了反复的输入数据、调试、改动代码的循环。而且那个活动提供的编译器很难用，这导致了我的效率大大的降低。当时我一边反复输入数据，一边非常的渴望有一个测试能够帮助我快速的得到反馈。
测试使我安心，而TDD，切实的让我感到效率得到了提升，而且每次能够想的更全面。
DDT是一件在提倡测试的团队，甚至是习惯甚严的TWU都经常发生的事。作为dev来说，总是有一颗快速实现代码，快速看到成果的欲望，每次看到一个功能，第一个浮现在脑海里的就是实现代码。所以每次拿到一个功能，在进行了任务拆分之后，最常做的事情就是开始开发。测试？完成了之后再补。在我所在的团队中，偶尔会在代码回顾的会议上听到“之后再补测试”这种话。环境有的时候就像洪水猛兽，当自己有如此想法的时候，加上周围环境的催化，很容易就会习以为常，慢慢就放下了习惯了的TDD。
一次偶然的机会，我二刷了一下《测试驱动开发》，有了一些不同的感受，突然想再次实践一下TDD。那一次，我参照着AC，将所有我能想到的各种情况通过测试反映出来。然后我发现，我的错误能够很快地发现，而且我不会漏掉AC，也可以很好的将边界情况覆盖到。这之后每一次，我都有意识的将测试提前，同时我可以拿着我的测试case找qa进行核对，看看是否有没有覆盖到的情况。
如果只是单纯的从理论上来说，测试或者说TDD是质量保证的一环，对于效率的提升这一点因人而异。在我写这篇文章的时候，主任提到有人曾经反对过TDD，提过客户不愿为TDD买单。对于大牛来说，我不敢妄加揣测。单纯作为一个一开发或者一重构就会心怀恐慌的dev来说，TDD保证的是某种程度上的开发的质量和效率，而客户买的就是代码的质量和效率，就让TDD对于他们来说是个黑盒吧。（仅个人观点，如有不到的地方，欢迎指正）
