借助Java 5 注释，JUnit 4 比从前更轻（量级），也更加灵活。JUnit 4 放弃了严格的命名规范和继承层次，转向了一些令人激动的新功能。下面是一份关于 JUnit 4 新功能的快速列表：
l 参数测试
l 异常测试
l 超时测试
l 灵活固件
l 忽略测试的简单方法
l 对测试进行逻辑分组的新方法。
让我们来一个一个整理。兵马未动，注解先行。注解先行之前，公共资源也要都要先准备好。我们现在before，after，beforeClass，afterClass开始。
1，Fixture相关注解：
何谓Fixture？汉语翻译就是： 它是指在执行一个或者多个测试方法时需要的一系列公共资源或者数据，例如测试环境，测试数据等等。在编写单元测试的过程中，我们会发现在大部分的测试方法在进行真正的测试之前都需要做大量的铺垫——为设计准备 Fixture 而忙碌。这些铺垫过程占据的代码往往比真正测试的代码多得多，而且这个比率随着测试的复杂程度的增加而递增。当多个测试方法都需要做同样的铺垫时，重复代码的“坏味道”便在测试代码中弥漫开来。这股“坏味道”会弄脏我们的代码，还会因为疏忽造成错误，应该使用一些手段来根除它。JUnit 专门提供了设置公共 Fixture 的方法，同一测试类中的所有测试方法都可以共用它来初始化 Fixture 和注销 Fixture。和编写 JUnit 测试方法一样，公共 Fixture 的设置也很简单，我们只需要：
1），使用注解 org.junit.Before 修饰用于初始化 Fixture 的方法。
2），使用注解 org.junit.After 修饰用于注销 Fixture 的方法。
和普通的测试方法一样，保证这两种方法都使用 public void 修饰，而且不能带有任何参数。遵循上面的三条原则，编写出的代码大体是这个样子：
这样，在每一个测试方法执行之前，JUnit 会保证setUp方法已经提前初始化测试环境，而当此测试方法执行完毕之后，JUnit 又会调用tearDown方法注销测试环境。注意是每一个测试方法的执行都会触发对公共 Fixture 的设置，也就是说使用注解 Before 或者 After 修饰的公共 Fixture 设置方法是方法级别的（setUp-->test1-->tearDown-->setUp-->test2-->teatDown。。。）。这样便可以保证各个独立的测试之间互不干扰，以免其它测试代码修改测试环境或者测试数据影响到其它测试代码的准确性。
可是，这种 Fixture 设置方式还是引来了批评，因为它效率低下，特别是在设置 Fixture 非常耗时的情况下（例如设置数据库链接）。而且对于不会发生变化的测试环境或者测试数据来说，是不会影响到测试方法的执行结果的，也就没有必要针对每一个 测试方法重新设置一次 Fixture。因此在 JUnit 4 中引入了类级别的 Fixture 设置方法，编写规范如下：
1），使用注解 org.junit.BeforeClass 修饰用于初始化 Fixture 的方法。
2），使用注解 org.junit.AfterClass 修饰用于注销 Fixture 的方法。
保证这两种方法都使用 public static void 修饰，而且不能带有任何参数。类级别的 Fixture 仅会在测试类中所有测试方法执行之前执行初始化，并在全部测试方法测试完毕之后执行注销方法（init-->test1-->test2-->destroy）。代码范本如下：
2，Test相关注解：
OK，现在重点来了，我们研究下Test注解。
毫无疑问的，和3.8版本的junit一样，测试方法必须是public void的，并且不带任何参数。然后我们用@Test注解来修饰这个方法，就表示这个方法是一个测试方法了。这个不在赘述了。
关于这个注解我主要是想介绍下@Test注解的异常测试和时间测试。
1），注解 org.junit.Test 中有两个非常有用的参数：expected 和timeout。参数 expected 代表测试方法期望抛出指定的异常，如果运行测试并没有抛出这个异常，则 JUnit 会认为这个测试没有通过。这为验证被测试方法在错误的情况下是否会抛出预定
的异常提供了便利。举例来说，方法 supportDBChecker 用于检查用户使用的数据库版本是否在系统的支持的范围之内，如果用户使用了不被支持的数据库版本，则会抛出运行时异常 UnsupportedDBVersionException。测试方法
supportDBChecker 在数据库版本不支持时是否会抛出指定异常的单元测试方法大体如下：
2），注解 org.junit.Test 的另一个参数 timeout，指定被测试方法被允许运行的最长时间应该是多少，如果测试方法运行时间超过了指定的毫秒数，则JUnit认为测试失败。这个参数对于性能测试有一定的帮助。例如，如果解析一份自定义的 XML 文档花费了多于 1 秒的时间，就需要重新考虑 XML 结构的设计，那单元测试方法可以这样来写：
OK，常用的注解基本就是这几个，现在来写一个例子，演示一下这些常用注解的用法。
OK，测试通过。
到此这篇junit4（junit4注解有哪些）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/bcyy/19856.html