This test checks that two JUnit test methods run independently without sharing state. It verifies that the counter variable resets for each test method, ensuring test independence.
Test independence in JUnit - Test Execution Trace
Test Overview
Test Code - JUnit 5
JUnit
import static org.junit.jupiter.api.Assertions.assertEquals; import org.junit.jupiter.api.BeforeEach; import org.junit.jupiter.api.Test; public class CounterTest { private int counter; @BeforeEach void setUp() { counter = 0; } @Test void testIncrementOnce() { counter++; assertEquals(1, counter); } @Test void testIncrementTwice() { counter++; counter++; assertEquals(2, counter); } }
Execution Trace - 4 Steps
| Step | Action | System State | Assertion | Result |
|---|---|---|---|---|
| 1 | JUnit framework initializes test class instance and calls @BeforeEach method | counter variable is set to 0 | — | PASS |
| 2 | testIncrementOnce method runs and increments counter by 1 | counter value is 1 | assertEquals(1, counter) verifies counter is 1 | PASS |
| 3 | JUnit framework initializes new test class instance and calls @BeforeEach method again | counter variable is reset to 0 | — | PASS |
| 4 | testIncrementTwice method runs and increments counter by 2 | counter value is 2 | assertEquals(2, counter) verifies counter is 2 | PASS |
Failure Scenario
Failing Condition: If the counter variable is shared between tests and not reset, the second test will fail because counter will not start at 0.
Execution Trace Quiz - 3 Questions
Test your understanding
Why does the counter variable reset to 0 before each test method?
Key Result
Always reset shared state before each test method using setup methods like @BeforeEach to ensure tests run independently and do not affect each other.
Practice
1.
What does test independence mean in JUnit testing?
Choose the best explanation.
easy
Solution
Step 1: Understand test independence concept
Test independence means tests do not rely on each other's results or states.Step 2: Compare options with definition
Only Each test runs without depending on the results or state of other tests. correctly states that tests run alone without dependencies.Final Answer:
Each test runs without depending on the results or state of other tests. -> Option DQuick Check:
Test independence = tests run alone [OK]
Hint: Tests should not rely on others to pass [OK]
Common Mistakes:
- Thinking tests must run in order
- Sharing data between tests
- Reusing objects without reset
2.
Which JUnit annotation is best used to prepare fresh data before each test to ensure test independence?
easy
Solution
Step 1: Identify setup annotations in JUnit
@BeforeEach runs before every test method, preparing fresh data each time.Step 2: Match annotation to test independence need
@BeforeClass runs once before all tests, not before each, so it doesn't ensure fresh data per test.Final Answer:
@BeforeEach -> Option BQuick Check:
@BeforeEach prepares fresh data [OK]
Hint: Use @BeforeEach for fresh setup before every test [OK]
Common Mistakes:
- Using @BeforeClass which runs only once
- Confusing @AfterAll with setup
- Not using any setup annotation
3.
Consider this JUnit test class snippet:
class CounterTest {
int count = 0;
@Test
void testIncrement() {
count++;
assertEquals(1, count);
}
@Test
void testReset() {
assertEquals(0, count);
}
}What will happen if these tests run in this order without any setup method?
medium
Solution
Step 1: Analyze shared variable usage
The variable count is shared across tests and not reset before each test, leading to order dependency.Step 2: Consider test order impact
If testIncrement runs first: count++ to 1, assert 1 passes (leaves count=1); testReset: assertEquals(0, 1) fails. If testReset first: assert 0 (initial) passes (leaves 0), testIncrement ++ to 1 passes. Thus, testReset may fail due to shared state.Final Answer:
testIncrement passes but testReset may fail due to shared count state. -> Option AQuick Check:
Shared state causes test order dependency [OK]
Hint: Shared variables cause test order dependency [OK]
Common Mistakes:
- Assuming tests run isolated without setup
- Ignoring shared mutable state
- Thinking manual reset in testReset fixes all issues
4.
Identify the problem in this JUnit test class and how to fix it to ensure test independence:
class ListTest {
List<String> list = new ArrayList<>();
@Test
void testAdd() {
list.add("item");
assertEquals(1, list.size());
}
@Test
void testClear() {
list.clear();
assertEquals(0, list.size());
}
}medium
Solution
Step 1: Identify shared mutable state
The list is a shared instance variable and is not reset before each test, causing tests to affect each other.Step 2: Apply proper setup for independence
Initializing the list inside a method annotated with @BeforeEach ensures a fresh list before every test, maintaining independence.Final Answer:
Problem: list is shared and not reset; Fix: initialize list in @BeforeEach method. -> Option AQuick Check:
Use @BeforeEach to reset shared objects [OK]
Hint: Reset shared objects in @BeforeEach for independence [OK]
Common Mistakes:
- Making list final does not reset contents
- Reordering tests does not guarantee independence
- Using static list shares state across tests
5.
You have a JUnit test class where one test modifies a static shared resource, causing other tests to fail intermittently.
How can you redesign the tests to maintain test independence and avoid flaky failures?
hard
Solution
Step 1: Understand static shared resource issue
Static resources are shared across all tests and can cause interference if modified without reset.Step 2: Apply test independence principle
To ensure independence, avoid static shared mutable state or reset it before each test by creating fresh instances in @BeforeEach.Step 3: Evaluate other options
Running tests sequentially or resetting once after all tests does not guarantee independence. Combining tests reduces clarity and independence.Final Answer:
Avoid using static shared resources; initialize fresh instances in @BeforeEach. -> Option CQuick Check:
Fresh instances per test ensure independence [OK]
Hint: No static shared state; fresh setup each test [OK]
Common Mistakes:
- Relying on test order or sequence
- Resetting static resource only once
- Merging tests reduces clarity and independence
Recommended
Ready to prove it?
Pass the test and this pattern moves unknown
10 questions ~5 mineasy hard
