测试驱动？很傻很天真

我一直认为测试驱动开发可以保证质量，如果要保证质量也必须实行测试驱动开发。我也确实是这么做的，但是就在上个周末，我辛苦“经营”的测试驱动的项目已经倒下了。

 

就是在上个周五的下午，客户突然说要求改动，好家伙，这个改动实在是太大了，保守的估计也需要3-5天吧。可是客户竟然要求当天晚上必须全部修改完毕！

 

我简直要崩溃了，我怀疑客户到底是用什么部位在进行思考，看着新的需求，脑袋一团乱，怎么可能一个下午作完3-5天的活？？

无奈归无奈，活还是要做滴。看着如此多，如此新的需求，我分析了半天，决定从其中一块开始入手。我打开了测试工程，在DataSet中增加了一个新的表，写了一个测试，然后运行测试..............天哪！竟然提示连接数据库错误！

怎么搞滴！赶紧看看吧，发现只有这新增加的表会出这个问题！此时忽然记起曾经有一位同仁修改过测试工程的配置。我的头大了！

 

众所周知，M$的产品一旦出现错误，就是那种千奇百怪，难以发现，折磨死人的错误。我分析，google解药，竟然找不到原因！

客户催得紧，这边VS又偏偏不争气，在我被郁闷了两个小时以后，终于无奈的决定，挥泪斩掉测试工程！

 

速度，客户要求的只有速度，我也一样。质量？见鬼去吧！

 

终于在凌晨12点的时候，我完成了1/3的需求。同时进行了“简单”的测试。到这个阶段，整个项目的1/3的代码已经被我修改了。我的心理实在没有底，只好请求另一个同仁能周六和我一起加班，他进行测试，我仍然进行修改。

 

就这样，目前的这个项目只用了短短的2天，就脱离了测试，脱离了持续集成。而当初，我们可是花了1个月时间来积累它的。

 

所以，正所谓形势比人强啊！我无奈了。

 

看着机器里的半死的测试工程，想想自己之前还很得意于项目的测试驱动和持续集成，突然觉得“很傻很天真”这个词是如此的亲切。