Behind the Code

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

2010-03-09  昨天雪，今天冷

昨天已经有童鞋提测了，今天测试MM开始了基于单元测试的测试流程，明天我们就可以拿到一个对比的报告了，很期待。第一个完整流程指日可待。

今天遇到的一个情况是测试驱动开发的反复。

• 有童鞋对测试用例有了一些疑问
• 有童鞋恢复到了以前的模式，先写功能性代码，然后用用例才测试

疑问是这样的，他在开发中，遇到了大量的遗留代码的问题，这时候在对已有代码的信任度上已经产生了质疑，他总是觉得要覆盖更多的内容才放心，但是这样却觉得UnitTest写起来没完没了了。
我对这个的回答是从两个方面进行的

1. 因为这次是第一次采用UnitTest，所以一定会出现大量的以前藏着的雷被踩到。
2. 已有的代码，我们这次假定是信任的，如果真的有问题，我们暂时绕过去，并告知测试和原有代码维护人员。因为如果不这样我们是无法定义用例覆盖的边界的。而遗留代码的问题，是应该相关的维护者补充对应的测试用例来覆盖的。

测试驱动开发是一个循环的事情，坚持住了，往前走就是良性循环，被遗漏的代码越来越少，雷区越来越少，代码质量提升。但是如果往后走，总觉得没时间写，总是有大量的不可覆盖不可测试的代码，每写一点就趟雷，会严重的打击士气，然后就不写了，然后就恶性循环了。

让我觉得非常受打击的一个事情是有些童鞋回到以往的开发模式了。先写功能代码，然后用用例开覆盖功能代码，起到测试的作用。
我记得我多次提过这样的危害，但是还有童鞋跑了回去，晚上只好那他开刀进行CodeReview。结果发现了一些设计和场景层面没有照顾到的地方。在此，我再说一次用 UnitTest 会带来的好处，当然这里只是说了一些对于开发者最明显的好处

• 用用例覆盖场景，因为我们考虑的是场景并且有测试人员配合，所以我们不容易遗漏场景
• 写TestCase是在进行设计，从使用者的角度，从API设计者的角度去看代码，会让设计更加自然
• 用功能性代码覆盖用例，功能性代码有保障
• 测试时期发生Bug容易定位
• 为测试节省时间，比如边界测试等都可以通过TestCase来进行，而无需每次都人肉
• 等

我决定他下一个任务我和他结对编程。

行百里者半九十，古人诚不欺我。