由 不写测试 到 补测试 再到 第一次有了测试先行的冲动。
写 java 的时候，在第一家公司都是给银行开发系统，都有专门的框架，只需要让我们补 service 层，也有一堆专门的测试人员，我们是不写测试的。后来去另一个创业的小公司，居然我的水平也是担当了开发主力。每天都是不断写代码，也不知测试为何物。
再后来，转学 rails 了。rails 虽然国内使用的很少，可是一般都要求写测试。而且我们学习的时候老师也有强调，虽然也没怎么学测试怎么写。第一家 rails 公司的技术总监就特别重视测试，也很崇尚 TDD（测试驱动开发，测试先行）。我刚开始十分不习惯，由于几乎没写过测试，对写测试的那套代码也不熟，通过 google 和参考项目中别人写的测试，我每次写测试都费了九牛二虎之力。有一次忘写测试了，还被批了一顿。我那时真的害怕写测试啊。
后来，技术总监给我推荐了《测试驱动开发》那本书，我也硬着头皮看完了，还看了两遍。读完后，了解了 TDD 的很多好处和一些测试的流程。虽然表面上知道了很多TDD 的好处，但我心里还是很害怕写测试。应了那句话，纸上得来终觉浅。
这次，我终于第一次有了测试先行的冲动！因为项目用了些 gem ，修改代码后不重启服务会超级慢。所以每次改完代码都去重启。然而来回重启去测试代码，一旦出错或者有逻辑错误的话，必须再次改代码，再次重启继续测，循环往复，花的时间特别长。所以，我想起来先写测试的好处了。如果我先有了测试，只需要一键就可运行看到结果。
写测试的时候，最讨厌的是要去构造数据，有些数据结构还比较复杂，另外也一直觉得添加测试代码会拖慢进度，构造完数据，还得去构造场景，尤其是进度一直赶着你的时候，写测试的时间就更觉得是浪费了。但是很多时候的偷懒，却带来了更大的不便，快（不写测试）变成了慢，慢（写测试）变成了快。
TDD 崇尚的是测试先行，即没写代码呢，就先写测试。好处是，如果先写测试，必然得知道输入是什么，期望输出的是什么。这样就不断促进思考该如何得到这样的输出，即把设计代码也放入了测试前期的准备中。构思差不多了，可以通过写伪代码的形式快速得到期望值。然后再去一步步把伪代码变成真正的代码。运行测试的时候有可能就变红了（出错了）。改好代码，再次运行，有可能就变绿了（运行正常）。觉得代码写的不太好，重构一下，再运行测试校验重构是否正确，如果变红，继续更改代码，直到再次变绿。这个过程就是 TDD 的过程。也是由红到绿再重构，然后再继续循环，直到觉得代码不需重构且都 Green. （Red Green Refactor为一个循环）。
像我开头说的，我现在是先写代码，通过浏览器测试直到代码正确，最后再去补测试。如果以 TDD 的过程写代码，我就不需要来回重启服务，在浏览器测试代码了，这个节省的时间是大把的，对我这个情境来说更是了。虽然浏览器测试省去了构造数据，模拟场景这些初期写测试不熟的人觉得很麻烦的步骤，但是却也少了测试先行的众多优点。何况写完代码之后一般是必定要写测试的，那提前一步写，其实并没有减慢整体的速度。只不过是写测试手生，被进度赶的慌了神，心里上就觉得写测试耽误时间了。
第一次有了测试先行的冲动。值得记录一下。