可以看出，目前JUnit（4.8版）对参数化测试的支持也不如NUnit，其局限性体现在：

　　● 测试类必须引入构造函数来接收由Test Runner传入的参数。

　　● 测试类的参数个数是固定的，由其构造函数确定。

　　希望今后的版本会得到加强。

　　4.3.3 引入类继承体系

　　引入继承体系也是一种代码复用的常见形式，把共同代码放入基类中，而把特有代码放入派生类中，如下图所示：

　　4.4 单一职责原则

　　对于一个类，我们要求它“has only one reason for change”；对于一个方法，我们要求它“does one thing and does it well”；同样地，对一个测试方法，我们要求它“test one thing only”。要做到这一点，可以从以下几方面入手。

　　4.4.1 在一个测试方法中仅使用一条断言语句

　　当一个测试方法中出现了多条断言语句时，实际上说明该测试方法是在测试多件事情了。这时我们可以有两种方法解决：

　　把一个测试方法拆分成多个测试方法。如果拆分的过程导致违背了DRY原则，那么可以使用前一节所讲到的技术来进行重构。

　　如果这多个断言语句实际上是在测试同一件事情的多个方面的话，可以考虑将这些断言语句合并成一条断言语句。

　　4.4.2 在一个测试方法中仅使用一个mock对象

　　当一个测试方法中使用了不止一个mock对象时，说明该测试方法不是只测试一件事情。

　　4.5 最小耦合原则

　　最小耦合原则反映在单元测试代码中时，即要求保证每个测试方法之间是完全隔离、互不影响的。这就要求：

　　测试方法之间不应有时间耦合，即它们的相对执行顺序是不会影响测试结果的。一个测试方法的通过与否不应该依赖于其它测试方法是否已被执行。

　　测试方法之间不能彼此调用。

　　测试方法之间不能共享状态和信息。

　　4.6 测试代码的可读性

　　本节我们来看一下测试代码可读性方面的一些指导方针。

　　4.6.1 保持测试代码的逻辑简单

　　应该避免在测试代码中引入逻辑. 具体地讲，测试代码中不应该出现if，switch-case，for/foreach，while，try-catch这样的语句。测试代码就应该只是顺序执行式代码。

　　4.6.2 对测试代码采用命名规范

　　采用整齐一致的命名规范可以使我们的测试代码更能被其他程序员理解。下面是我们推荐的命名规范。