Assert List Contents JUnit 5 | Java Fresher
Fast recall
Quick revision
Core answer
assertEquals(expectedList, actual) for order-sensitive equality, assertTrue(actual.contains(x))), but AssertJ is far more expressive: assertThat(list).hasSize(2).containsExactly(a, b) or .extracting(Order::id).containsExactlyInAnyOrder(...). Choose containsExactly (order matters) vs containsExactlyInAnyOrder (order doesn't) deliberately.Interview-ready guide
Interview answer
Asserting only the size of a list is weak, because a test that just checks the list has two elements still passes if those two elements are completely wrong. So I want to assert the actual contents.
With core JUnit, I can do assertEquals between an expected list and the actual list, which checks equality including order, or I can use assertTrue with contains to check membership. That works, but for collections AssertJ is much more expressive and reads better. I'd write assertThat the list, then chain hasSize and containsExactly with the elements I expect.
The distinction I'm careful about is order. containsExactly means the same elements in the same order, so it fails if the order is different. containsExactlyInAnyOrder means the same elements but order doesn't matter, which is what I'd use for something like a database query result where the order isn't guaranteed. And plain contains just checks that certain elements are present without caring about the rest. Picking the wrong one is a classic source of flaky tests — using containsExactly on an unordered result will fail intermittently.
AssertJ also has extracting, which is really handy. Instead of comparing whole objects, I can extract a property — say the id of each order — and then assert on that list of ids. That's useful when the objects don't override equals, because containsExactly relies on equals. So
Assert List Contents JUnit 5 | Java Fresher
Direct Answer
To verify a returned list, you can use core JUnit (assertEquals(expectedList, actual) for order-sensitive equality, assertTrue(actual.contains(x))), but AssertJ is far more expressive: assertThat(list).hasSize(2).containsExactly(a, b) or .extracting(Order::id).containsExactlyInAnyOrder(...). Choose containsExactly (order matters) vs containsExactlyInAnyOrder (order doesn't) deliberately.
Deep Dive & Architecture
A useful list assertion starts with the method contract: must the order match, must every element match, or does only membership matter? Core JUnit can compare two lists with assertEquals, using the lists’ equality rules, which include element order. AssertJ offers more explicit collection checks.
For example, assertThat(result).containsExactly("A", "B") proves both contents and order, while containsExactlyInAnyOrder("A", "B") proves the same contents when ordering is not part of the contract. contains("A") allows extra values and is therefore weaker. For domain objects, extracting(Order::id) can compare stable properties instead of relying on whole-object equality. A size-only assertion is not enough: a two-element list can still contain the wrong two elements.
Code Example
List<Order> result = service.findExpensive(50.0);
// Weak: only checks count
assertEquals(2, result.size());
// Core JUnit: order-sensitive full equality
assertEquals(List.of(orderA, orderB), result);
// AssertJ: expressive and readable
assertThat(result)
.hasSize(2)
.containsExactly(orderA, orderB); // order matters
// Assert a property across all elements, order-independent
assertThat(result)
.extracting(Order::id)
.containsExactlyInAnyOrder("O1", "O2");
Common Mistakes & Pitfalls
- Only asserting size.
hasSize(2)passes with the wrong two elements; assert contents. - Wrong order semantics. Using
containsExactlyon an unordered query result causes flaky failures; use...InAnyOrder. - Comparing objects without
equals.containsExactlyrelies onequals; useextractingon a key field if not overridden. - Manual loops. Hand-rolled for-loops with asserts are noisy; AssertJ collection matchers are clearer.
Check your understanding
Answer these without looking back at the article.
- What is the Arrange-Act-Assert (AAA) pattern in unit testing?
- How do you use assertThrows to test exception scenarios in JUnit 5?
- How do you test floating point numbers in JUnit 5?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.