project-root/
├── src/
│ ├── main/
│ │ └── java/
│ │ └── com/example/app/
│ │ └── (application source code)
│ └── test/
│ ├── java/
│ │ └── com/example/app/
│ │ ├── stubs/ <-- Stub objects here
│ │ │ └── UserServiceStub.java
│ │ ├── utils/ <-- Test utilities and helpers
│ │ ├── pages/ <-- Page objects if UI tests
│ │ └── tests/ <-- JUnit test classes
│ │ └── UserServiceTest.java
│ └── resources/ <-- Test data, config files
├── build.gradle or pom.xml <-- Build and dependency management
Stub objects in JUnit - Framework Patterns
- Stub Layer: Contains stub classes that simulate behavior of real dependencies with fixed responses.
- Test Layer: JUnit test classes that use stubs to isolate the unit under test.
- Utility Layer: Helper methods for common test setup or assertions.
- Configuration Layer: Environment and test settings loaded from resources or system properties.
- Application Layer: The real application code under test.
Use src/test/resources to store environment-specific config files like test.properties or stub-config.yaml.
Use system properties or environment variables to switch between real and stub implementations if needed.
Example: In JUnit tests, inject stub objects directly or via dependency injection frameworks configured for test scope.
JUnit generates XML and HTML reports by default when run via build tools like Maven or Gradle.
Integrate these reports into CI/CD pipelines (Jenkins, GitHub Actions) to show pass/fail status and test coverage.
Stub usage helps tests run fast and reliably, improving CI feedback speed.
- Keep stubs simple: Return fixed data only, avoid complex logic to keep tests predictable.
- Isolate tests: Use stubs to isolate the unit under test from external dependencies.
- Place stubs in a dedicated package: Helps maintain clear separation from real code and test classes.
- Use descriptive names: Name stub classes clearly to indicate their purpose (e.g.,
UserServiceStub). - Document stub behavior: Comment what fixed responses the stub provides to help future maintainers.
Where in this folder structure would you add a new stub object for a PaymentService?
Practice
stub object in JUnit testing?Solution
Step 1: Understand the role of stub objects
Stub objects are used to replace real parts of a system with simple implementations that return fixed data.Step 2: Identify the purpose in testing
This allows tests to run in isolation and control the test environment by providing predictable responses.Final Answer:
To replace a real object with fixed responses for controlled testing -> Option AQuick Check:
Stub objects = fixed responses for isolation [OK]
- Confusing stubs with mocks or spies
- Thinking stubs generate random data
- Believing stubs fix bugs automatically
Solution
Step 1: Recognize Java anonymous class syntax
Creating a stub often uses an anonymous class overriding methods to return fixed values.Step 2: Check each option's syntax
MyService service = new MyService() { public int getValue() { return 5; } }; correctly overridesgetValue()to return 5. Options A, C, and D have invalid Java syntax.Final Answer:
MyService service = new MyService() { public int getValue() { return 5; } }; -> Option CQuick Check:
Anonymous class override = MyService service = new MyService() { public int getValue() { return 5; } }; [OK]
- Trying to assign a value directly to a method call
- Using incorrect method call syntax
- Confusing lambda syntax with anonymous classes
testService.getValue()?
class TestService {
int getValue() { return 0; }
}
TestService testService = new TestService() {
@Override
int getValue() { return 10; }
};
System.out.println(testService.getValue());Solution
Step 1: Understand method overriding in anonymous class
The anonymous class overridesgetValue()to return 10 instead of 0.Step 2: Determine output of the print statement
CallingtestService.getValue()invokes the overridden method, so it returns 10.Final Answer:
10 -> Option DQuick Check:
Overridden method returns 10 [OK]
- Assuming original method runs instead of overridden
- Thinking anonymous class causes compile error
- Expecting runtime exceptions without errors
MyService service = new MyService() {
public int getValue() {
return "five";
}
};Solution
Step 1: Check method return type consistency
The methodgetValue()is declared to returnint, but returns aString"five".Step 2: Verify syntax correctness
The anonymous class syntax and semicolon are correct; overriding is allowed.Final Answer:
Method getValue returns wrong data type -> Option BQuick Check:
Return type mismatch causes error [OK]
- Ignoring return type mismatch
- Assuming syntax error instead of type error
- Thinking overriding is disallowed
Solution
Step 1: Identify the problem with the real service
The external service is slow, which slows down tests and makes results unpredictable.Step 2: Choose a stub approach for speed and predictability
Creating a stub that returns fixed data instantly allows fast, reliable tests without depending on the real service.Step 3: Evaluate other options
Using the real service or skipping tests delays feedback; mocking without return data doesn't help test results.Final Answer:
Create a stub class that returns fixed, pre-defined data instantly -> Option AQuick Check:
Stub fixed data = fast, predictable tests [OK]
- Using real slow service in tests
- Confusing mocks with stubs
- Skipping tests instead of isolating dependencies
Ready to prove it?
Pass the test and this pattern moves unknown
