Boundary Condition Testing JUnit 5 | Java Fresher Interview
Fast recall
Quick revision
Core answer
[min, max], test min-1, min, max, max+1 (and often 0, empty, and null). Parameterized tests express this as a compact table so you systematically cover the boundaries instead of one happy-path value — most off-by-one bugs live exactly at these edges.Interview-ready guide
Interview answer
The core idea behind boundary testing is that bugs cluster at the edges of a valid range, not in the middle. Most of them are off-by-one errors — using less-than where you meant less-than-or-equal, that kind of thing. So testing one value in the middle of the range proves almost nothing about where the bugs actually live.
The technique is boundary value analysis. For a valid range from min to max, I test four key points: just below min, exactly min, exactly max, and just above max. I usually throw in a clearly valid middle value too. So if a rule says an age has to be between eighteen and sixty-five inclusive, I'd test seventeen as invalid, eighteen as valid, sixty-five as valid, and sixty-six as invalid. The seventeen and sixty-six cases are what catch the off-by-one mistakes. I'd also add special cases that often break on their own — zero, negative numbers, empty strings, null, and overflow values like Integer max.
Parameterized tests are the perfect tool for this, because I can put all those edges into a single CsvSource table and run one test body against all of them. That makes the coverage systematic and easy to read, and adding a boundary is just another row. I give it a name pattern so each row is labelled, because when a boundary fails I want to know immediately which one.
This pairs with equivalence partitioning, where I group inputs into classes — invalid-low, valid, invalid-high — and pick representatives, then focus on the edges between them.
Boundary Condition Testing JUnit 5 | Java Fresher Interview
Direct Answer
Boundary testing checks the edges where bugs cluster: for a valid range [min, max], test min-1, min, max, max+1 (and often 0, empty, and null). Parameterized tests express this as a compact table so you systematically cover the boundaries instead of one happy-path value — most off-by-one bugs live exactly at these edges.
Deep Dive & Architecture
Boundary testing checks values where behavior changes, because off-by-one mistakes usually live there. For an inclusive range [min, max], useful cases are just below min, exactly min, just above min, one ordinary value, just below max, exactly max, and just above max.
For example, an age rule accepting 18 through 65 can use @CsvSource rows for 17,false, 18,true, 19,true, 64,true, 65,true, and 66,false. The expected result belongs in the same row, so every decision is visible. Invalid-input cases that should throw can use a separate parameterized test with assertThrows. Do not generate many random middle values while omitting the edges; the boundary points carry the most information.
Code Example
// Rule: age must be in [18, 65] inclusive to be eligible
@ParameterizedTest(name = "age {0} -> eligible={1}")
@CsvSource({
"17, false", // min - 1 (just below)
"18, true", // min (lower edge)
"40, true", // mid (clearly valid)
"65, true", // max (upper edge)
"66, false" // max + 1 (just above)
})
void checksAgeEligibility(int age, boolean expected) {
assertEquals(expected, policy.isEligible(age));
}
// Special cases worth their own rows: 0, negative, Integer.MAX_VALUE
Common Mistakes & Pitfalls
- One value only. Testing age 40 proves nothing about the 18/65 edges where off-by-one bugs live.
- Skipping just-outside. min-1 and max+1 catch
<vs<=mistakes. - Ignoring specials. 0, empty string, null, and overflow values often break separately.
- Vague labels. Without a
namepattern, a failing boundary row is hard to identify.
Check your understanding
Answer these without looking back at the article.
- What is @ParameterizedTest and what sources can you use?
- How do you use @CsvSource for testing multiple input-output pairs?
- How do you use @MethodSource for complex parameterized test arguments?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.