If you allocate external resources in a {@link Before} method you need to release them after the test runs. Annotating a <code>public void</code> method with <code>@After</code> causes that method to be run after the {@link Test} method. All <code>@After</code> methods are guaranteed to run even if a {@link Before} or {@link Test} method throws an exception. The <code>@After</code> methods declared in superclasses will be run after those of the current class, unless they are overridden in the current class. <p> Here is a simple example: <pre> public class Example { File output; @Before public void createOutputFile() { output= new File(...); } @Test public void something() { ... } @After public void deleteOutputFile() { output.delete(); } } </pre>
If you allocate expensive external resources in a {@link BeforeClass} method you need to release them after all the tests in the class have run. Annotating a <code>public static void</code> method with <code>@AfterClass</code> causes that method to be run after all the tests in the class have been run. All <code>@AfterClass</code> methods are guaranteed to run even if a {@link BeforeClass} method throws an exception. The <code>@AfterClass</code> methods declared in superclasses will be run after those of the current class, unless they are shadowed in the current class. <p> Here is a simple example: <pre> public class Example { private static DatabaseConnection database; @BeforeClass public static void login() { database= ...; } @Test public void something() { ... } @Test public void somethingElse() { ... } @AfterClass public static void logout() { database.logout(); } } </pre>
When writing tests, it is common to find that several tests need similar objects created before they can run. Annotating a <code>public void</code> method with <code>@Before</code> causes that method to be run before the {@link Test} method. The <code>@Before</code> methods of superclasses will be run before those of the current class, unless they are overridden in the current class. No other ordering is defined. <p> Here is a simple example: <pre> public class Example { List empty; @Before public void initialize() { empty= new ArrayList(); } @Test public void size() { ... } @Test public void remove() { ... } } </pre>
Sometimes several tests need to share computationally expensive setup (like logging into a database). While this can compromise the independence of tests, sometimes it is a necessary optimization. Annotating a <code>public static void</code> no-arg method with <code>@BeforeClass</code> causes it to be run once before any of the test methods in the class. The <code>@BeforeClass</code> methods of superclasses will be run before those of the current class, unless they are shadowed in the current class. <p> For example: <pre> public class Example { @BeforeClass public static void onlyOnce() { ... } @Test public void one() { ... } @Test public void two() { ... } } </pre>
Sometimes you want to temporarily disable a test or a group of tests. Methods annotated with {@link Test} that are also annotated with <code>@Ignore</code> will not be executed as tests. Also, you can annotate a class containing test methods with <code>@Ignore</code> and none of the containing tests will be executed. Native JUnit 4 test runners should report the number of ignored tests along with the number of tests that ran and the number of tests that failed.
The <code>Test</code> annotation tells JUnit that the <code>public void</code> method to which it is attached can be run as a test case. To run the method, JUnit first constructs a fresh instance of the class then invokes the annotated method. Any exceptions thrown by the test will be reported by JUnit as a failure. If no exceptions are thrown, the test is assumed to have succeeded. <p> A simple test looks like this: <pre> public class Example { <b>@Test</b> public void method() { Assert.assertTrue( new ArrayList().isEmpty() ); } } </pre> <p> The <code>Test</code> annotation supports two optional parameters. The first, <code>expected</code>, declares that a test method should throw an exception. If it doesn't throw an exception or if it throws a different exception than the one declared, the test fails. For example, the following test succeeds: <pre> @Test(<b>expected=IndexOutOfBoundsException.class</b>) public void outOfBounds() { new ArrayList<Object>().get(1); } </pre> If the exception's message or one of its properties should be verified, the {@link rules.ExpectedException ExpectedException} rule can be used. Further information about exception testing can be found at the <a href="https://github.com/junit-team/junit/wiki/Exception-testing">JUnit Wiki</a>. <p> The second optional parameter, <code>timeout</code>, causes a test to fail if it takes longer than a specified amount of clock time (measured in milliseconds). The following test fails: <pre> @Test(<b>timeout=100</b>) public void infinity() { while(true); } </pre> <b>Warning</b>: while <code>timeout</code> is useful to catch and terminate infinite loops, it should <em>not</em> be considered deterministic. The following test may or may not fail depending on how the operating system schedules threads: <pre> @Test(<b>timeout=100</b>) public void sleep100() { Thread.sleep(100); } </pre> <b>THREAD SAFETY WARNING:</b> Test methods with a timeout parameter are run in a thread other than the thread which runs the fixture's @Before and @After methods. This may yield different behavior for code that is not thread safe when compared to the same test method without a timeout parameter. <b>Consider using the {@link rules.Timeout} rule instead</b>, which ensures a test method is run on the same thread as the fixture's @Before and @After methods.