http://blog.blogchina.com/article_25255.99548.html
gzeric 于 2004年 09月06日 发表
真正接触Junit，也就是大概3个月前，上头给了个新的头衔我——主持团队里的测试工作，第一个目标就是完善unit testing的制度。Junit几乎是java开发中unit testing的唯一选择，无论是收费的Jbuilder，还是Share的IntelliJ IDEA，甚至是Free的Eclipse都选择集成了Junit。到底是什么东西使Junit散发着如此大的魅力呢？
Unit testing就像是整个Testing工程中的cell，所有测试应该都是base on unit testing的，java的unit testing主要针对的是每个java class的测试。
Junit对每个unit的testing都定义了一个TestCase，这个case理论上是应该针对某一个class，用户可以应自身的需要定义一系列的fixtures，然后根据实际情况编写test method，然后对test result做出相应的assertion。这就是一个比较完整的Junit TestCase了。
Unit testing有一个不成文的方程式，objective test + replicable test = simple test programme，可以看出objective和replicable是unit testing的最关心的两样东西。objective意味着每个TestCase都应该是有目的的，并非人云亦云的“每个class都应该进行unit testing”；replicable则意味着TestCase应该是可重用的。Junit作为一个unit testing的framework，十分好的尊重了这两条原则，很大程度上都由编写TestCase的人员来控制objective特性，而且replicable的方法和API也很大程度地提高了开发人员在编写TestCase上的效率。只要开发人员真正认识到了unit testing的必要性，他就一定会喜欢junit带来的好处，并非单纯的跟风的学习和使用。要知道Junit是能够真正提高开发效率和代码质量的。
在Junit的扩展上，业内有几个相对出名的项目，但我这里想说说的是Cactus和Httpunit。Cactus是针对容器内的一种junit扩展，它把TestCase扩展为JSP、Sevlet和Filter三种形式，然后通过一些特殊的方法（如beginXXX等）来定义一个测试过程，来模拟一系列交互的容器内测试；Httpunit则是定义了一个WebConversation，然后针对web形式的response和request来模拟browser的所有动作以及结果，同样的Httpunit也可以模拟容器内的测试，如servlet的。相比之下，我个人认为Httpunit更加从根本上解决了web形式的测试问题，可以说是更加原始的测试，通过request和response的形式来模拟整个交互过程，而且还提供了对link的测试，应该来说更加容易让用户真切体会到它的优势所在。反倒是Cactus在测试前就必须通过一大轮配置，更加令我苦恼的是用Cactus很难去模拟一个完整的流程，只能够通过多个test method来不断测试各个servlet method，然后只能证明这些methods没有问题，很难说明这些methods串起来后不出问题。
本文地址：http://com.8s8s.com/it/it15169.htm