Class Assertions

java.lang.Object
org.junit.jupiter.api.Assertions

@API(status=STABLE, since="5.0") public class Assertions extends Object
Assertions is a collection of utility methods that support asserting conditions in tests.

Unless otherwise noted, a failed assertion will throw an AssertionFailedError or a subclass thereof.

Object Equality

Assertion methods comparing two objects for equality, such as the assertEquals(expected, actual) and assertNotEquals(unexpected, actual) variants, are only intended to test equality for an (un-)expected value and an actual value. They are not designed for testing whether a class correctly implements Object.equals(Object). For example, assertEquals() might immediately return true when provided the same object for the expected and actual values, without calling equals(Object) at all. Tests that aim to verify the equals(Object) implementation should instead be written to explicitly verify the Object.equals(Object) contract by using assertTrue() or assertFalse() — for example, assertTrue(expected.equals(actual)), assertTrue(actual.equals(expected)), assertFalse(expected.equals(null)), etc.

Kotlin Support

Additional Kotlin assertions can be found as top-level functions in the org.junit.jupiter.api package.

Preemptive Timeouts

The various assertTimeoutPreemptively() methods in this class execute the provided callback (executable or supplier) in a different thread than that of the calling code. If the timeout is exceeded, an attempt will be made to preemptively abort execution of the callback by interrupting the callback's thread. If the callback's thread does not return when interrupted, the thread will continue to run in the background after the assertTimeoutPreemptively() method has returned.

Furthermore, the behavior of assertTimeoutPreemptively() methods can lead to undesirable side effects if the code that is executed within the callback relies on ThreadLocal storage. One common example of this is the transactional testing support in the Spring Framework. Specifically, Spring's testing support binds transaction state to the current thread (via a ThreadLocal) before a test method is invoked. Consequently, if a callback provided to assertTimeoutPreemptively() invokes Spring-managed components that participate in transactions, any actions taken by those components will not be rolled back with the test-managed transaction. On the contrary, such actions will be committed to the persistent store (e.g., relational database) even though the test-managed transaction is rolled back. Similar side effects may be encountered with other frameworks that rely on ThreadLocal storage.

Extensibility

Although it is technically possible to extend this class, extension is strongly discouraged. The JUnit Team highly recommends that the methods defined in this class be used via static imports.

Since:
5.0
See Also: