以下是对JUnit实践的一个很好的总结信息来源于一些比较权威的JUnit书籍和网上资料这里集合如下
每次只对一个对象进行UT测试（unittest one object at a time）这样能使你尽快发现问题而不被各个对象之间的复杂关系所迷惑
给测试方法起个好名字（choose meaningful test method names）应该是用形如testXXXYYY()这样的格式来命名你的测试方法前缀test是Junit查找测试方法的依据XXX应该是你测试的方法名YYY应该是你测试的状态当然如果你只有一种状态需要测试可以直接命名为testXXX()
明确写出出错原因（explain the failure reason in assert calls）在使用assertTrueassertFalseassertNotNullassertNull方法时应该将可能的错误的描述字符串以第一个参数传入相应的方法这样你可以迅速的找出出错原因
一个UT测试方法只应该测试一种情况（one unit test equals one testMethod）一个方法中的多次测试只会混乱你的测试目的
测试任何可能的错误（test anything that could possibly fail）你的测试代码不是为了证明你是对的而是为了证明你没有错因此对测试的范围要全面比如边界值正常值错误值对代码可能出现的问题要全面预测
让你的测试帮助改善你的代码（let the test improve the code）测试代码永远是我们代码的第一个用户所以不仅让他帮组我们发现Bug还要帮组我们改善我们的设计就是有名的测试驱动开发（TestDriven DevelopmentTDD）
一样的包不同的位置（same package separate directories）测试的代码和被测试的代码应该放到不同的文件夹中建议使用这种目录 src/java/代码 src/test/测试代码 这样可以让两份代码使用一样的包结构但是放在不同的目录下
关于setup与teardown
a) 不要用TestCase的构造函数初始化Fixture而要用setUp()和tearDown()方法
b) 在setUp和tearDown中的代码不应该是与测试方法相关的而应该是全局相关的如针对与测试方法都要用到的数据库链接等等
c) 当继承一个测试类时记得调用父类的setUp()和tearDown()方法
不要在mock object中牵扯到业务逻辑（dont write business logic in mock objects）
只对可能产生错误的地方进行测试（only test what can possibly break）如一个类中频繁改动的函数对于那些仅仅只含有getter/setter的类如果是由IDE（如Eclipse）产生的则可不测如果是人工写那么最好测试一下
尽量不要依赖或假定测试运行的顺序因为JUnit利用Vector保存测试方法所以不同的平台会按不同的顺序从Vector中取出测试方法
避免编写有副作用的TestCase你要确信保持你的测试方法之间是独立的
将测试代码和工作代码放在一起一边同步编译和更新（使用Ant中有支持junit的task）
确保测试与时间无关不要依赖使用过期的数据进行测试导致在随后的维护过程中很难重现测试
如果你编写的软件面向国际市场编写测试时要考虑国际化的因素不要仅用母语的Locale进行测试
尽可能地利用JUnit提供地assert/fail方法以及异常处理的方法可以使代码更为简洁
测试要尽可能地小执行速度快
……等待你的高见！
