Why different doubles serve different purposes in JUnit - Framework Benefits

Framework Mode - Why different doubles serve different purposes

Folder Structure for JUnit Test Project with Test Doubles

  src/
  ├── main/
  │   └── java/
  │       └── com/example/app/
  │           └── Service.java
  └── test/
      └── java/
          └── com/example/app/
              ├── ServiceTest.java
              ├── doubles/
              │   ├── DummyUserRepository.java
              │   ├── FakePaymentGateway.java
              │   ├── StubEmailSender.java
              │   └── MockNotificationService.java
              └── utils/
                  └── TestUtils.java
  

Test Framework Layers and Roles of Test Doubles

• Test Layer: Contains JUnit test classes like ServiceTest.java where tests run.
• Test Doubles Layer: Contains different doubles:
  • Dummy: Objects passed but never used, just to fill parameters.
  • Stub: Provide canned answers to calls, no logic.
  • Fake: Have working implementations but simplified (e.g., in-memory DB).
  • Mock: Objects that record interactions to verify behavior.
• Utilities Layer: Helper methods for creating doubles or test data.
• Production Code Layer: Actual application code under test.

Configuration Patterns for Using Test Doubles in JUnit

• Dependency Injection: Inject doubles into classes under test via constructors or setters.
• Profiles or Tags: Use JUnit tags or profiles to run tests with different doubles if needed.
• Properties Files: Configure environment-specific settings if doubles depend on config.
• Mockito Integration: Use Mockito annotations like @Mock and @InjectMocks for mocks.

Test Reporting and CI/CD Integration

• JUnit generates XML and HTML reports showing test pass/fail status.
• Reports include details on tests using doubles to verify behavior.
• CI/CD pipelines (e.g., Jenkins, GitHub Actions) run tests automatically on commits.
• Failures in tests with doubles help quickly identify issues in interaction or logic.

Best Practices for Using Different Test Doubles

• Use Dummies only to fill unused parameters to keep tests clean.
• Use Stubs to provide fixed responses for simple method calls.
• Use Fakes when you want a lightweight but working implementation (e.g., in-memory DB).
• Use Mocks to verify interactions and behavior precisely.
• Keep doubles simple to avoid complex logic inside test code.

Self-Check Question

Where in this folder structure would you add a new fake implementation for a caching service?

Key Result

Different test doubles serve distinct roles: dummy for unused params, stub for canned answers, fake for simple working implementations, and mock for interaction verification.

Practice

1. Which test double is primarily used to provide predefined data to the code under test without verifying interactions?

easy

A. Stub

B. Mock

C. Spy

D. Fake

Solution

1. Step 1: Understand the role of a stub

   A stub provides fixed data or responses to the code being tested but does not check if methods were called.

2. Step 2: Differentiate from mocks and spies

   Mocks verify interactions, spies do both spying and stubbing, and fakes are simplified implementations. Only stubs focus on providing data without verification.

3. Final Answer:

   Stub -> Option A

4. Quick Check:

   Stub = provides data only [OK]

Hint: Stubs give data, mocks check calls, spies do both [OK]

Common Mistakes:

• Confusing mocks with stubs
• Thinking spies only provide data
• Mixing fakes with stubs

2. Which of the following is the correct way to create a mock object using Mockito in JUnit?

easy

A. MyClass mock = spy(new MyClass());

B. MyClass mock = new MyClass();

C. MyClass mock = Mockito.mock(MyClass.class);

D. MyClass mock = new FakeMyClass();

Solution

1. Step 1: Recall Mockito syntax for mocks

   Mockito.mock(Class.class) creates a mock object for the given class.

2. Step 2: Identify incorrect options

   MyClass mock = new MyClass(); creates a real object, not a mock. MyClass mock = spy(new MyClass()); creates a spy, not a mock. MyClass mock = new FakeMyClass(); uses a fake class, not a mock.

3. Final Answer:

   MyClass mock = Mockito.mock(MyClass.class); -> Option C

4. Quick Check:

   Mockito.mock() creates mocks [OK]

Hint: Use Mockito.mock(Class.class) to create mocks [OK]

Common Mistakes:

• Using new keyword instead of Mockito.mock
• Confusing spy() with mock()
• Assuming fake classes are mocks

3. Given the following code snippet using Mockito:

List<String> list = Mockito.spy(new ArrayList<>());
list.add("one");
Mockito.verify(list).add("one");
System.out.println(list.size());

What will be printed?

medium

A. 0

B. null

C. Throws an exception

D. 1

Solution

1. Step 1: Understand spy behavior

   A spy wraps a real object and records interactions but calls real methods unless stubbed.

2. Step 2: Analyze the code execution

   Adding "one" to the spy list calls the real add method, so the list size becomes 1. The verify confirms the add call happened.

3. Final Answer:

   1 -> Option D

4. Quick Check:

   Spy calls real methods and records calls [OK]

Hint: Spy calls real methods and tracks calls [OK]

Common Mistakes:

• Thinking spy does not call real methods
• Assuming size remains 0 after add
• Expecting null or exception output

4. Identify the error in this Mockito test code:

MyService service = Mockito.mock(MyService.class);
service.process();
Mockito.verify(service.process());

medium

A. Missing MockitoAnnotations.initMocks(this) call

B. verify() should receive a method call without parentheses

C. verify() should be called before process()

D. process() method cannot be mocked

Solution

1. Step 1: Understand Mockito verify syntax

   Mockito.verify() expects the mock object as argument, then the method call without parentheses inside verify.

2. Step 2: Identify the mistake in code

   The code calls verify(service.process()), which calls process() immediately and passes its result. Correct is verify(service).process().

3. Final Answer:

   verify() should receive a method call without parentheses -> Option B

4. Quick Check:

   Use verify(mock).method() syntax [OK]

Hint: Use verify(mock).method() without parentheses inside verify [OK]

Common Mistakes:

• Calling method inside verify() parentheses
• Calling verify before method execution
• Confusing mock initialization with verification

5. You want to test a method that calls an external payment service. You need to check that the payment method was called with correct parameters, but also want to return a fixed success response. Which test double should you use?

hard

A. Mock

B. Spy

C. Stub

D. Fake

Solution

1. Step 1: Understand requirements for the test double

   You want to verify the method call (like a mock) and also provide a fixed response (like a stub).

2. Step 2: Identify the double that combines both features

   A mock verifies interactions and can return fixed responses when configured with when(mock.method(params)).thenReturn(success).

3. Final Answer:

   Mock -> Option A

4. Quick Check:

   Mock = verify calls + stub data [OK]

Hint: Mock verifies calls and stubs responses [OK]

Common Mistakes:

• Using stub which can't verify calls
• Using spy which executes real methods unless stubbed
• Confusing fake with mock