TDD Test-Driven Development Java | Fresher Interview
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
TDD stands for Test-Driven Development, and it's a cycle where you write the test before the code. The loop has three steps: Red, Green, Refactor. Red means I write a test for a feature that doesn't exist yet, so it fails. That forces me to think about what the method should do — its name, its inputs, its outputs — before I write any implementation. Green means I write the simplest possible code to make that test pass. I'm not trying to build the perfect solution, just enough to turn the bar green; sometimes that's even a hardcoded value, and that's fine. Refactor means I clean up the code while keeping the tests green — remove duplication, improve names, extract methods — and the tests are my safety net proving I didn't change behavior.
The big benefit is that TDD drives better design. If a class is hard to test, it's usually because it has too many dependencies or it's doing too much. TDD makes me feel that pain upfront. For example, if I'm writing a test for an order service and I realize I need to mock five things, that's a design smell telling me to rethink the responsibilities. TDD builds useful regression coverage as behavior is added, but it does not guarantee that every path or edge case is tested.
A common mistake is confusing TDD with just writing tests — TDD specifically means test first; writing tests afterward doesn't give you the design benefit. Another is writing too much code in the green phase.
TDD Test-Driven Development Java | Fresher Interview
Direct Answer
TDD (Test-Driven Development) is a cycle where you write a failing test first, write just enough code to pass it, then refactor while tests stay green — the Red-Green-Refactor loop. Writing the test first forces you to design the API from the caller's view, builds regression coverage as behavior is added, and surfaces bad design early because hard-to-test code signals tight coupling.
Deep Dive & Architecture
Test-Driven Development repeats a short loop. Red: write one small test for behavior that does not yet exist and confirm it fails for the expected reason. Green: add the simplest production code that makes it pass. Refactor: improve names and structure while the suite remains green. Then choose the next behavior and repeat.
For example, a password validator may begin with one failing test for a blank password, add the smallest blank check, then add separate tests for length and required characters. Writing from the caller’s point of view exposes awkward APIs and excessive dependencies early. TDD supports focused design and steady regression coverage, but it does not guarantee complete coverage or a good architecture; weak assertions and missing scenarios are still possible.
Code Example
// 1) RED — write the failing test first
@Test
void shouldRejectPasswordShorterThan8Characters() {
var result = new PasswordValidator().validate("abc123");
assertThat(result.valid()).isFalse();
assertThat(result.error()).isEqualTo("Password must be at least 8 characters");
} // fails to compile: PasswordValidator doesn't exist yet
// 2) GREEN — simplest code that passes
record ValidationResult(boolean valid, String error) {}
class PasswordValidator {
ValidationResult validate(String pw) {
if (pw.length() < 8)
return new ValidationResult(false, "Password must be at least 8 characters");
return new ValidationResult(true, null);
}
}
// 3) REFACTOR — remove the magic number, tests stay green
class PasswordValidator2 {
private static final int MIN = 8;
ValidationResult validate(String pw) {
return pw.length() < MIN
? new ValidationResult(false, "Password must be at least " + MIN + " characters")
: new ValidationResult(true, null);
}
}
Common Mistakes & Pitfalls
- Calling test-after "TDD." TDD specifically means the test comes first; tests written afterward tend to describe what the code does, not what it should do.
- Over-building in Green. Writing the whole feature once the test compiles. Write only enough to pass; add complexity in the next cycle.
- Skipping Refactor. Green tests don't mean clean code. Refactoring while green is when you pay down duplication safely.
- Testing implementation, not behavior. Verifying private calls makes tests break on every refactor even when behavior is unchanged.
Check your understanding
Answer these without looking back at the article.
- What is JUnit and why does it exist? It provides a lightweight framework for writing and running repeatable unit tests in Java so that regressions are caught early and design feedback is continuous.
- Why is unit testing important in software development?
- What makes a good unit test?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.