JUnit 5 Assertions | Java Fresher Interview

In JUnit 5, assertions are static methods on the Assertions class, and I usually import them statically so I can just call assertEquals directly. The one I use most is assertEquals, and the important detail is that the expected value comes first and the actual value second. That ordering matters because the failure message reads expected this but was that — if you swap them, the message is backwards and misleads you while debugging.

Beyond assertEquals, there's assertTrue and assertFalse for booleans, assertNull and assertNotNull for references, and assertThrows for exceptions. assertThrows is really useful because it doesn't just check that an exception was thrown — it returns the exception object, so I can then assert on its message or its cause. That's much cleaner than the old try-catch-then-fail pattern.

For example, assertEquals(10, calculator.add(3, 7)) verifies a returned value, while assertThrows(IllegalArgumentException.class, () -> account.withdraw(-1)) verifies an invalid call and returns the exception for further checks.

There's also assertAll, which lets me group several assertions together. Normally separate assertions stop at the first failure, but assertAll runs all of them and reports every failure at once, which is handy when I'm checking several fields of one object. And there's assertSame, which checks reference identity with double-equals rather than value equality — I rarely need it.

One gotcha is calling assertEquals on objects that don't override equals — it falls back to reference comparison and fails even when the values match. In practice a lot of teams add AssertJ on top, so you write assertThat(price).isEqualTo(ninety), which reads more naturally for complex objects and collections.