Given When Then BDD Testing | Java Fresher Interview
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Given When Then is a pattern from Behavior-Driven Development that structures tests in three parts. Given describes the starting state or preconditions. When describes the action you take. Then describes what you expect to happen. So testing a discount feature, it's: Given a customer has premium status, When they place an order over a hundred dollars, Then they get a fifteen percent discount. It's basically the same as Arrange, Act, Assert, the technical way of organizing tests, but Given When Then uses business language instead of programmer language.
The pattern comes from BDD, created to help non-technical people like product managers collaborate on requirements. Tools like Cucumber let you write tests in plain English using this pattern: a feature file with Given, When, Then in real sentences, and Java code that implements each step. But you don't need Cucumber. You can structure regular JUnit tests the same way, using blank lines to separate the three sections, or even just putting Given When Then in the test name.
Use it when you're testing business logic or user-facing behavior that a non-technical person cares about. Use Arrange, Act, Assert for technical code like utility functions where there's no business context. The mistake freshers make is thinking BDD means you must use Cucumber. It doesn't — BDD is a way of thinking about tests as specifications. Another mistake is mixing technical jargon into the sentences, like Given a UserDTO with a premium flag, instead of just Given a premium customer, which defeats the readability you're after.
Given When Then BDD Testing | Java Fresher Interview
Direct Answer
Given-When-Then structures tests as Given (initial state), When (action), Then (expected outcome) — the BDD equivalent of Arrange-Act-Assert. Tools like Cucumber use it in plain-English feature files, but you can apply the same structure in plain JUnit through naming or code organization, no framework required.
Code Example
import java.math.BigDecimal;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;
class DiscountServiceTest {
private final DiscountService service = new DiscountService();
// GWT lives in the name; the body uses blank lines for the three phases
@Test
void givenPremiumCustomer_whenCalculateDiscount_thenApplies15Percent() {
// Given: a premium customer and an order amount
var amount = new BigDecimal("100");
// When: the discount is calculated
var discount = service.calculateDiscount(amount, "PREMIUM");
// Then: 15 percent is applied
assertEquals(new BigDecimal("15.00"), discount);
}
}
// A Cucumber feature file expresses the same in Gherkin:
// Given a premium customer
// When I calculate the discount on 100 dollars
// Then the discount should be 15 percent
Common Mistakes & Pitfalls
- Thinking BDD requires Cucumber — it's a way of thinking applicable in any framework via clear structure and naming.
- Mixing technical and business language — 'Given a UserDTO with isPremium=true' instead of 'Given a premium customer' defeats readability.
- Over-engineering with Cucumber — adding feature files and glue code for a small team with no non-technical stakeholders when plain JUnit suffices.
Check your understanding
Answer these without looking back at the article.
- What is Cucumber and how does it implement BDD in Java?
- How do you write a Gherkin feature file?
- What is the difference between TDD and BDD?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.