最近在修改别人代码,修改别人代码总是让人头疼。虽然重构可以让我们减轻些负担,但担子还是很重。周末时去买了本《修改代码的艺术》,这本书中又极力推荐通过测试来确保修改。我一直不看好测试,原因很简单如果我们针对产品代码写了测试,那么测试代码本身也可能有问题,于是你再写代码测试你的测试代码本身,噢,循环开始了:
产品代码->测试代码->测试[测试代码]......
是别人意淫了测试?但有直觉告诉我不是,直觉来自我自己一次次被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
阅读(1074) | 评论(0) | 转发(0) |