JUnit 5 Assertions and AssertJ — Fluent Test Assertions
Fast recall
Quick revision
Core answer
Whether the candidate knows modern assertion libraries beyond JUnit's built-in assertEquals and can write readable, maintainable assertions.
Using assertEquals for everything — including collections, optional values, and exceptions — leading to poor failure messages and unreadable tests.
Demonstrate AssertJ's fluent API for collections, exception assertions, soft assertions, and custom assertion classes.
Interview-ready guide
Interview answer
AssertJ provides a fluent API where assertions read like sentences: assertThat(list).hasSize(3).contains("item"). The key advantage over JUnit's assertEquals is failure messages — AssertJ shows the actual content, not just "expected 3 but was 5."
Collection assertions are where it shines: extracting(Order::getStatus).containsExactlyInAnyOrder(...) pulls a field from each element and asserts on the resulting list. This replaces streams, collects, and separate assertions.
Exception assertions chain naturally: assertThatThrownBy(() -> ...).isInstanceOf(UserNotFoundException.class).hasMessage(...) — one fluent chain instead of JUnit's assertThrows plus separate message checks.
Soft assertions collect all failures and report them at once — fix three bugs in one test run instead of three. Use them for independent field checks like DTO mapping verification.
JUnit 5 Assertions and AssertJ — Fluent Test Assertions
Direct Answer
AssertJ provides a fluent assertion API with descriptive failure messages. assertThat(result).isNotNull().hasSize(3).contains("item") reads like a sentence and produces clear failure output.
Common Mistakes & Pitfalls
Using assertEquals for everything — including collections, optional values, and exceptions — leading to poor failure messages and unreadable tests.
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.