补测试用例有感

最近这个迭代一直在写单元测试，准确的说是补充单元测试。自己对单元测试又有了进一步的认识，技术的学习就和交朋友一样，了解是一步一步加深的。简单的单元测试就不多说了，无非是建立一个测试类，然后在这个测试类当中调用被测试的类，然后就是Assert一下自己预期的结果和实际的结果是否一致，如果预期的结果与实际的结果一致，那么就证明要测试的类基本上是没有问题的。但是最近补单元测试的过程着实让自己痛苦不堪。悲催的笔者前不久还说过不写单元测试的程序员是多么的可恶，自己现在终于“如愿以偿”的“写”（补）单元测试了。现在笔者越发的痛恨不写单元测试的程序员了，因为写完程序之后让别人补单元测试是一件比不写单元测试更加龌龊的事情。补充单元测试的人一般是补充一个包中所有的类，甚至所有子包中所有的类的测试用例。这就需要这个补充测试的人员去了解多个业务逻辑，这无疑为写测试用例增加了难度。可以这么说，写一个覆盖率超过80%的测试类的时间丝毫不少于重新写一个原有的业务逻辑类的时间。尤其是写关于SessionBean的测试类，因为要在容器中进行测试（使用mock，这里推荐Junit in action这本书，单击此处下载）这就相当于每次进行测试都启动一个小的EJB容器（目前菜鸟笔者没有找到更好的办法，望大牛赐教哇）然后进行业务逻辑的测试，然后当数据持久化之后还要Assert持久后的数据是否和预期的一致，这就不得不将持久化后的数据拿出来Assert，这好像已经违背了单元测试的初衷了。补了将近半个月的单元测试自己对一个理想的可测试的类有如下几个认识（不服来辩）l 不应该在启动容器的情况下才能测试l 所有与容器有关的东西甚至是所有外界资源都应该是可以被注入的l 方法应该是尽量单独职能的l 测试类和被测试类的作者必须是同一个人l 测试类的创建时间可以早于被测试类（TDD）或者稍微晚一些（目的是避免写测试的时候被测试的类逻辑都不记得了）l 方法应该是具有非void返回值的 我知道以上几个要求都是奢望，因为以上种种祈求都会迎来开发人员常常挂在嘴边的话“时间紧任务重哪有时间……”于是后面补测试用例的人就命苦了，比如笔者自己……

（愿全世界人民和平共处，愿每个程序员都能写单元测试）