Behind the Code

作者：yinwm
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明。

2010-03-08 鹅毛中雪

今天早上中午还都是平平淡淡的过去的，没有波澜，只有不惊。唯一的不同时窗外白茫茫的世界。从夜里开始下雪，周围已经都白了，天气也冷了，这是什么天啊。2012？

下午吃饭前1小时的时候，我们决定提前进行CodeReview，按照某些人的说法就是“爽一下，然后去吃饭”。
今天上战场的小哥是一个测试开发人员，我已经单独的给他Review过至少三次代码，代码的质量已经好了很多了，让他上去游街我还是比较放心的。
不明真相的群众纷纷前来围观，我们又开始激烈的讨论，今天的讨论让人为之一振。

今天我们没有过多的纠缠在编码风格等地方，究其原因应该是：

1. 经过一周的训练，小哥的编码已经没有太大的问题了
2. 经过一周的围观，群众的见识已经大大的不一样了

取而代之的是，我们花了很大的篇幅来讨论 TestCase 应该怎么写；测试断言应该到什么粒度；测试时候是否相信（一个）函数的功能；重构时候函数抽取到底应该包含那些；等等，不一而足。讨论非常激烈，而且也第一次出现了双方的论述都有道理，都无法彻底的说服对方的情况。这是一个好的现象，说明我们已经上升到了一个思辨的层面，也说明我们已经开始有能力站在稍微高一点的层次来看待开发这点事儿了。
今天分歧最大的一点在于几个开发人员认为用例覆盖的太过于细致，被抽象出来的一个创建对象的方法里面进行了大量的检查，这是没必要的。而负责写用例的童鞋是测试人员，他认为是非常有必要的。从而展开了一场声势浩大的拉歌比赛。
我个人从如下三点来理解这个问题和分歧的：

1. 要考虑代码是经过多次重构长起来的
   今天大家看到的代码其实是重构了多次，一点点的生长起来的。在重构的过程中，一定会出现为了几个地方差不多，略有不同但是本质上可以放在一起的情况，这时候把他们重构到一个方法中不能说不合适。而这时候造成的结果可能就是这个方法只能上稍微有一些臃肿。这时候我们可以选择职能继续拆分，或者是忍。可是忍了，这些（逻辑上可能）多余的代码怎么办？
2. TestCase 中无副作用的多余的代码如何处理
   我个人写 TestCase 的习惯是这样的。写好的断言，如果不是非要删除不可，一般我都会留下。因为这不是功能性代码，这地方稍微罗嗦一点没关系，而且说不准哪天会用上。而最重要的理由则是，这些代码没有副作用。当然了，如果某些断言耗时很长，那就属于有副作用了，如果没用，坚决干掉。
3. 每个人的职责不同，看问题的角度不同
   还有一个问题就是大家看到的问题的角度是不同的，开发看的是用例应该体现设计思路、单一职能，要简洁。而测试人员看到的是我不相信一切，我要覆盖到一切可以覆盖的地方。而引申出来则是开发童鞋看到的用例应该测试单元，而测试童鞋的用例则是为了覆盖场景。
   这个思辨的过程是我第一次想到的，也是我觉得收获最大的一点。如果我们认为测试和开发是站两边，现在团队已经开始在朝着中间靠拢了。我记得我说过一句话，就是开发的单元测试用熟练以后是应该朝着覆盖场景前进的。这也算是我们为了以后更大规模的自动测试前进了一小步吧。
   随着测试驱动开发的锻炼，我相信开发人员都会有一颗测试的心。

还有，期间有童鞋说，写断言没错，但是如果是多个断言，可能会打断正常的思路。
这里面我给出的答案是“采用占位方法”。说起来很简单，就是在需要写大量代码的地方，给出一个占位的方法，这个方法的职责就是去完成那需要多行代码组合起来的功能。这时候就不怕思绪被打乱了，而且这个方法还没有，编译/运行肯定不过，也不怕回来忘了。

今日Milestone，测试人员已经开始测试了。给出了一个任务，要求测试的MM和功能开发的兄弟明天一起给出一个报告。这个报告是要对比使用 TestCase 前后的不同的。其中应该包括Bug的数量、回归的时间、问题的定位等。
完成了这一步，我们的测试驱动开发才能算是完成了一个完整的循环。