@BeforeEach @AfterEach JUnit 5 | Java Fresher Interview
Fast recall
Quick revision
Core answer
@TestFactory do not each receive a separate before/after-each cycle.Interview-ready guide
Interview answer
@BeforeEach and @AfterEach are lifecycle hooks around each Jupiter test invocation. I use the before hook to create the fixture that several tests share and the after hook to release per-test resources. For a shopping cart, the before hook can create an empty cart before each test.
Under the default PER_METHOD lifecycle, JUnit creates a new test-class instance for each test method or invocation. That isolates ordinary instance fields, but static fields, a database, files, and remote systems are still shared unless the test resets or isolates them. @AfterEach is invoked after a failed test, so it is the right lifecycle location for cleanup, although process termination and setup failures can still affect what cleanup is possible.
@BeforeAll and @AfterAll run once for the container. Under PER_METHOD they are normally static; PER_CLASS permits instance methods. Choose each versus all by resource scope, not only by setup cost.
@BeforeEach @AfterEach JUnit 5 | Java Fresher Interview
Direct Answer
@BeforeEach and @AfterEach are lifecycle hooks that run around each Jupiter test invocation. Use them to create the fixture needed by that test and release per-test resources. They support isolation, but only the code inside the hooks resets external or static state. Dynamic tests created by one @TestFactory do not each receive a separate before/after-each cycle.
Deep Dive & Architecture
@BeforeEach runs before every test invocation and prepares a clean fixture. @AfterEach runs afterward and releases per-test resources. This surrounding lifecycle also applies to each row of a parameterized test.
For example, @BeforeEach can create a new in-memory cart so one test’s items never appear in another test. @AfterEach can close a temporary server or clear a resource that the test opened. Expensive resources shared by the whole class belong in @BeforeAll and @AfterAll, not in per-test hooks. Setup should remain visible enough that a reader understands the scenario; hiding all inputs in a large @BeforeEach makes tests harder to read and can conceal unwanted shared assumptions.
Code Example
class ShoppingCartTest {
private ShoppingCart cart;
@BeforeEach
void setUp() { // runs before EVERY test
cart = new ShoppingCart(); // each test gets an empty cart
}
@Test
void newCartIsEmpty() {
assertEquals(0, cart.itemCount());
}
@Test
void addingItemIncreasesCount() {
cart.add(new Item("book", 10.0));
assertEquals(1, cart.itemCount()); // not polluted by other tests
}
@AfterEach
void tearDown() { // runs after EVERY test, even on failure
cart.clear();
}
}
Common Mistakes & Pitfalls
- Confusing Each with All.
@BeforeEachruns per test;@BeforeAllruns once. Heavy setup in@BeforeEachslows the suite, but shared mutable setup in@BeforeAllbreaks isolation. - Relying on leftover state. Expecting a field populated by a previous test — fragile and order-dependent. Build state in
@BeforeEach. - Cleanup in the test body. If the test fails before cleanup, resources leak. Put cleanup in
@AfterEach. - Using JUnit 4 names. It's
@BeforeEach/@AfterEach, not@Before/@After.
Check your understanding
Answer these without looking back at the article.
- What does @DisplayName do in JUnit 5 and why should you use it?
- What is @ExtendWith in JUnit 5 and when do you use it?
- What is @Nested in JUnit 5 and how does it improve test organization?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.