经验一、不要在测试用例的构造函数中做初始化
当我们需要增加一个测试时，我们要书写一个自己的测试用例，比如sometest。如果你喜欢在sometest的构造函数中做有关的初始化工作，这可不是个好习惯。如下例：
| public class sometest extends testcase{ public sometest(string testname){ super(testname); //初始化代码 } } |
一旦初始化代码产生异常，比如illegalstateexception，junit随之将产生一个assertionfailederror，并显示类似下面的出错信息：
| junit . framework . assertionfailederror : cannotinstantiatetestcase : test1at junit . framework . assert . fail ( assert . java : 143 ) at junit . framework . testsuite$1 . runtest ( testsuite . java : 178 ) at junit . framework . testcase . runbare ( testcase . java : 129 ) at junit . framework . testresult$1 . protect ( testresult .java : 100 ) at junit . framework . testresult . runprotected ( testresult. java: 117 ) at junit . framework . testresult . run ( testresult. java : 103 ) at junit . framework . testcase . run( testcase . java: 120 ) at junit . framework . testsuite . run( testsuite . java , compiledcode ) at junit . ui . testrunner$12 . run (testrunner. java : 429 ) |
这一大堆出错信息只会让人一头雾水，我们只知道junit无法实例化某个测试用例，到底出了什么问题，在哪儿出错了呢？不知道！那么好的做法是怎样呢？答案是重载测试用例的setup()方法进行初始化。当setup()中的初始化代码产生异常时我们得到的是类似下面的出错信息：
| java . lang . illegalstateexception : oopsatbp . dtc . setup ( dtc .java: 34 ) at junit . framework . testcase . runbare ( testcase .java: 127 ) at junit . framework . testresult$ 1 . protect(testresult . java : 100 ) at junit . framework . testresult . runprotected ( testresult . java: 117 ) at junit . framework . testresult . run ( testresult .java : 103 ) ... |
显然这要清楚得多我们一下子就可以知道是在dtc.java 的第34行产生了illegalstateexception
经验二、不要假定测试用例中测试的执行次序
我们知道在一个junit 的测试用例类中可以包含多个测试，每个测试其实就是一个method。在下面的例子中有两个不同的测试，尽管testdothisfirst()在位置上先于testdothissecond()，但我们不能就此假定testdothisfirst()会先执行。
| public class sometestcase extends testcase{ public sometestcase(string testname){ super(testname); } public void testdothisfirst(){ ... } public void testdothissecond(){ } } |
由于junit 内部使用一个vector 来存储所有的test，因此在不同的操作系统和java 虚拟机上，test 的执行次序是不可预测的。
好的习惯是保持测试之间的独立性，使得它们在任何次序下执行的结果都是相同的。如果真得需要某些测试按照特定的次序执行，我们可以借助addtest 来实现。如下例：
| public static testsuite(){ suite.addtest(new sometestcase(“testdothisfirst”;)); suite.addtest(new sometestcase(“testdothissecond”;)); return suite; } |
这样我们可以确保junit先执行testdothisfirst()，然后执行testdothissecond()。
经验三、测试要避免人工干预
如果某段测试代码需要人工干预，那至少有两个不良后果：一则不能被包括在自动测试中，比如夜间的回归测试；二则不能被重复执行，例如数据删除的测试不能做完删除就万事大吉，比较好的做法是自动补上删除掉的数据。经验二讲的是不同的测试要避免相关性，而经验三讲的其实就是测试要避免自相关。
经验四、在子类中调用父类的setup() 和teardown()
让我们看一看下面的代码
| public class sometestcase extends anothertestcase { // a connection to a database private database thedatabase; public sometestcase (string testname) { super (testname); } public void testfeaturex () { ... } public void setup () { // clear out the database thedatabase.clear (); } } |
你发现其中的错误了吗？setup()应该调用super.setup() 以确保anothertestcase 中定义的父类的环境被初始化了。当然这也有例外，就是基类可以处理任意的测试数据。
经验五、不要硬性规定数据文件的路径
我们经常需要从文件系统中读取测试数据，看下面的代码：
| public void setup () { fileinputstream inp ("c:\\testdata\\dataset1.dat"); ... } |
这段代码需要把测试数据文件dataset1.dat 放在c:\testdata，这是有问题的。
第一，c 盘可能没有磁盘空间了测试人员不得不把数据文件放到其他路径；
第二，可能需要在其他操作系统比如linux 上执行这一测试。
所以，一个较好的替代方案是
| public void setup () { fileinputstream inp ("dataset1.dat"); ... } |
但事实上这样仍不是很好，因为这要求数据文件的路径和测试执行的路径必须是同一个，如果几个不同的测试都这样的话，那要把这些测试集合起来执行就有些困难，我们不得不频繁的改变当前路径。
为了解决这个问题，我们可以使用class.getresource()或者class.getresourceasstream()，这样我们可以把数据文件放在这个class 的某个相对路径上。
数据文件应该尽可能和源代码一起都放在配置管理系统上，但这样一来如果我们采用上面的resource 机制，我们就需要做一件工作，就是把数据文件从原来的位置－就是源代码的某个相对路径，拷贝到编译后的位置，也就是class 文件的相应的相对路径。这其实并不复杂，因为从class 的 package 就可以映射到java文件的所在路径对于linux或者windows我们所要做的就是把package中的. 用 file.separatorchar 替代。
