两个pair两月工作之后的rake stats

关键还是web开发方式的转变，大多数非tdd开发都是开着web服务器来开发、调试。其实这种方式属于集成测试阶段的调试方式。这方面我经过两个多月（java）的实践得出的结论：
如果采用robbin事后补的做法，会出现如下情况：
1. 程序员为了提高覆盖率而测试
2. 很多逻辑没法测试（开发时候时间紧啊，代码与环境耦合度高，没法测试）
结果测试就是东测一些，西测一些


tdd一定要在开发阶段引入，要求程序员开发每一个api前都要编写相应的测试用例文档并且通过分析员的审核（这样子制度化了程序员就养成习惯了）。接下来编写api或者编写测试用例，哪个先都没所谓了，只要保证编写的测试用例根据上面的文档来的就ok了，上面的文档最大限度反应了这个api的真是真实需求。
把所有的后台开发完了，接下来开始开发页面了，这时候把web服务器启动起来，照着以前的开发模式开发页面，减少了服务器的启动时间，整体开发速度不会慢，质量又有保证了

除非是做产品的二次开发，或者类似这样已经有较成熟的领域代码的情况。否则，这样先后台再前端的顺序会出现与“整体开发速度不会慢，质量又有保证”完全相反的情况。

推荐Robbin用rspec on rails来写test。虽然还不太成熟，写出来的测试程序就象spec一样直观，顺便把spec一起补了。

rspec我研究过了，确实很棒，充分展示了ruby作为DSL的潜力。不过rspec现在还不支持rails的集成测试，所以不行。

对于我来说，写测试是为了保证代码质量，rails自己的集成测试可读性已经很好了，没有很强烈的需求改用rspec。说起来我最近也一直在研究rails的测试，传统的测试中后台代码的测试一般都问题不大，解决方案已经比较充分了，但是页面测试一直是一个难点。对于JSP来说，几乎是不可测试的，模板语言可测试，但是没有好的支持工具。只能求助于外在的selenium测试工具，但selenium也有自己的问题。

但rails不同，rails已经提供了非常强大而且简单的页面测试功能，特别是assert_select功能很强大，可以对response输出页面使用selector语法任意导航和断言，让页面测试变得极其简单。rails可以说是目前对于整套web应用程序测试支持最棒而且最酷的框架了。