最近在修改别人代码，修改别人代码总是让人头疼。虽然重构可以让我们减轻些负担，但担子还是很重。周末时去买了本《修改代码的艺术》，这本书中又极力推荐通过测试来确保修改。我一直不看好测试，原因很简单如果我们针对产品代码写了测试，那么测试代码本身也可能有问题，于是你再写代码测试你的测试代码本身，噢，循环开始了：
产品代码->测试代码->测试[测试代码]......
是别人意淫了测试？但有直觉告诉我不是，直觉来自我自己一次次被Legacy Code折磨。
自己不得其解，难受呀。忽然给别人一提点，对了测试原来是这样：
1，测试不是为了找Bug。[一定要驱走，曾经测试给我们的感觉]2，测试让我们的代码更有效。[如果一段代码被删除后，测试仍可心通过，那么这段代码就是多余的]3，在重构时增加测试，往往不是为了找出Bug。而是[确保软件行为，没有因为我们的重构而改变]4，在测试是遇到了[有些代码不能/不方便测试]，你会[调整代码]以方便测试，其实你是在做[设计,即Design]，不自然中，你解开了耦合。但还有些测试问题没有得到解决，让测试实践起来很难：
1，产品代码和测试代码应该如何布局？将其分开，还是掺杂在一起？
将其分开的话，测试点离问题点太远。不能起到测试即文档(注释)作用。
将其掺杂在一起的话，代码的长度必然加大，单个问题所用的代码过长，信息承载量必然加大。会阻碍维护时对代码/业务逻辑本身的理解。
2，如果业务逻辑性太长，如何测试？ 如果软测涉及到交互，如何测试？
比如你一套请假系统，涉及到很多判断条件，很多层级审批，你如何测试？
在请假系统中，系统要与数据库，LDAP，用户进行交互，你如何测试？
如果多层级审批与LDAP有依赖，你又如何测试？
谁来提点？
Jerry.Chou
4/21'09
PS.有两篇文章可供参考：
1，敏捷技术：顿悟测试驱动开发
2，实践测试驱动开发
http://dreamhead.blogbus.com/logs/14189175.html
阅读(1050) | 评论(0) | 转发(0) |
