Bird
Raised Fist0
JUnittesting~15 mins

@Spy for partial mocking in JUnit - Build an Automation Script

Choose your learning style10 modes available
Verify partial mocking using @Spy annotation in JUnit
Preconditions (2)
Step 1: Create a test class CalculatorTest
Step 2: Annotate a Calculator instance with @Spy
Step 3: Stub the multiply method to return a fixed value (e.g., 100) when called with any arguments
Step 4: Call the add method with inputs 5 and 3
Step 5: Call the multiply method with inputs 5 and 3
Step 6: Verify that add method returns the actual sum (8)
Step 7: Verify that multiply method returns the stubbed value (100)
✅ Expected Result: The add method returns 8 (real method execution), and multiply method returns 100 (stubbed). The test passes confirming partial mocking with @Spy.
Automation Requirements - JUnit 5 with Mockito
Assertions Needed:
Assert that add(5,3) returns 8
Assert that multiply(5,3) returns 100
Best Practices:
Use @ExtendWith(MockitoExtension.class) to enable Mockito annotations
Use @Spy annotation on the Calculator instance
Use Mockito.when() to stub multiply method
Use assertions from org.junit.jupiter.api.Assertions
Avoid stubbing methods unnecessarily
Use descriptive test method names
Automated Solution
JUnit
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.*;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.Spy;
import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
public class CalculatorTest {

    static class Calculator {
        public int add(int a, int b) {
            return a + b;
        }

        public int multiply(int a, int b) {
            return a * b;
        }
    }

    @Spy
    Calculator calculator;

    @Test
    void testPartialMockingWithSpy() {
        // Stub multiply method to always return 100
        when(calculator.multiply(anyInt(), anyInt())).thenReturn(100);

        // Call add method - real method should be called
        int sum = calculator.add(5, 3);

        // Call multiply method - stubbed method should be called
        int product = calculator.multiply(5, 3);

        // Verify results
        assertEquals(8, sum, "Add method should return real sum");
        assertEquals(100, product, "Multiply method should return stubbed value");
    }
}

This test class uses @ExtendWith(MockitoExtension.class) to enable Mockito annotations.

The Calculator class has two methods: add and multiply.

We annotate a Calculator instance with @Spy to create a partial mock. This means real methods are called unless stubbed.

We stub the multiply method to always return 100 regardless of input using when(...).thenReturn(...).

When calling add(5,3), the real method runs and returns 8.

When calling multiply(5,3), the stubbed method runs and returns 100.

Assertions verify these expected results, confirming partial mocking works as intended.

Common Mistakes - 4 Pitfalls
{'mistake': 'Using @Mock instead of @Spy for partial mocking', 'why_bad': "Mocks replace all methods with stubs by default, so real methods won't run unless explicitly told.", 'correct_approach': 'Use @Spy to create a partial mock where real methods run unless stubbed.'}
{'mistake': 'Not using @ExtendWith(MockitoExtension.class) with Mockito annotations', 'why_bad': "Mockito annotations like @Spy won't be initialized, causing NullPointerException.", 'correct_approach': 'Add @ExtendWith(MockitoExtension.class) on the test class to enable annotation processing.'}
{'mistake': 'Stubbing methods incorrectly with wrong argument matchers', 'why_bad': "If argument matchers don't match actual call, stub won't apply and real method runs unexpectedly.", 'correct_approach': 'Use correct argument matchers like anyInt() to match all inputs when stubbing.'}
Calling real methods on a @Mock instance expecting partial behavior
Bonus Challenge

Now add data-driven testing with 3 different input pairs for add and multiply methods using @Spy

Show Hint

Practice

(1/5)
1. What does the @Spy annotation do in JUnit testing?
easy
A. Automatically runs all test methods in a class.
B. Creates a completely fake object with no real method calls.
C. Creates a real object but allows overriding some methods for partial mocking.
D. Mocks static methods of a class.

Solution

  1. Step 1: Understand @Spy purpose

    @Spy creates a real instance of the class but allows selective method overriding.
  2. Step 2: Compare with other mocking types

    Unlike full mocks, spies call real methods unless stubbed.
  3. Final Answer:

    Creates a real object but allows overriding some methods for partial mocking. -> Option C
  4. Quick Check:

    @Spy = Partial real object with override [OK]
Hint: Remember: @Spy means real object with some fake methods [OK]
Common Mistakes:
  • Confusing @Spy with @Mock which creates full fake objects
  • Thinking @Spy mocks static methods
  • Assuming @Spy runs tests automatically
2. Which of the following is the correct way to initialize a spy object in a JUnit 5 test class using Mockito?
easy
A. @Spy MyClass mySpy; MockitoAnnotations.openMocks(this);
B. @Spy MyClass mySpy = new MyClass();
C. @Spy MyClass mySpy = Mockito.mock(MyClass.class);
D. @Spy MyClass mySpy = Mockito.spy(null);

Solution

  1. Step 1: Recognize proper spy initialization

    Using @Spy requires calling MockitoAnnotations.openMocks(this) to initialize the spy fields.
  2. Step 2: Check other options

    @Spy MyClass mySpy = new MyClass(); misses initialization call; C uses mock instead of spy; D tries spying on null which is invalid.
  3. Final Answer:

    @Spy MyClass mySpy; MockitoAnnotations.openMocks(this); -> Option A
  4. Quick Check:

    Initialize spies with openMocks(this) [OK]
Hint: Always call MockitoAnnotations.openMocks(this) to init @Spy [OK]
Common Mistakes:
  • Not calling MockitoAnnotations.openMocks(this)
  • Confusing spy creation with mock creation
  • Trying to spy on null or uninitialized objects
3. Given the following code snippet, what will be the output of the test?
@Spy
List<String> spyList = new ArrayList<>();

@Test
void testSpyList() {
    spyList.add("one");
    spyList.add("two");
    Mockito.doReturn(100).when(spyList).size();
    System.out.println(spyList.size());
}
medium
A. 2
B. 100
C. 0
D. Throws NullPointerException

Solution

  1. Step 1: Understand spy behavior with doReturn

    The spy calls real methods unless stubbed. Here, size() is stubbed to return 100.
  2. Step 2: Analyze output of spyList.size()

    Despite adding two elements, size() returns 100 due to stubbing.
  3. Final Answer:

    100 -> Option B
  4. Quick Check:

    Stubbed spy method returns stub value [OK]
Hint: Stub spy methods with doReturn to override real calls [OK]
Common Mistakes:
  • Expecting real method size() to return actual list size
  • Using when(spyList.size()) instead of doReturn for spies
  • Forgetting spy initialization causing NullPointerException
4. Identify the error in the following test code using @Spy:
@Spy
MyService service;

@Test
void testService() {
    service = new MyService();
    Mockito.doReturn("mocked").when(service).getData();
    assertEquals("mocked", service.getData());
}
medium
A. The spy object is not initialized with MockitoAnnotations.openMocks(this).
B. You cannot assign a new instance to a @Spy annotated field.
C. doReturn cannot be used with spy objects.
D. The assertEquals method is used incorrectly.

Solution

  1. Step 1: Check spy initialization

    The @Spy field must be initialized by calling MockitoAnnotations.openMocks(this) before use.
  2. Step 2: Analyze assignment and usage

    Assigning new instance manually is allowed but without initialization, spy won't work properly.
  3. Final Answer:

    The spy object is not initialized with MockitoAnnotations.openMocks(this). -> Option A
  4. Quick Check:

    Always init @Spy with openMocks(this) [OK]
Hint: Always initialize @Spy fields before test runs [OK]
Common Mistakes:
  • Forgetting to call MockitoAnnotations.openMocks(this)
  • Thinking manual assignment replaces initialization
  • Believing doReturn can't be used with spies
5. You want to partially mock a complex service class PaymentProcessor to test only the processPayment() method while keeping other methods real. Which approach using @Spy is best to achieve this?
hard
A. Create a new PaymentProcessor instance without @Spy and call processPayment() directly.
B. Mock the entire PaymentProcessor class with @Mock and implement processPayment() manually.
C. Use @Spy but override all methods except processPayment() to avoid side effects.
D. Create a spy of PaymentProcessor and stub only processPayment() method with Mockito.doReturn().

Solution

  1. Step 1: Understand partial mocking goal

    Partial mocking means real methods run except those stubbed.
  2. Step 2: Choose spy with selective stubbing

    Using @Spy and stubbing only processPayment() lets you test that method while others behave normally.
  3. Step 3: Evaluate other options

    Mocking entire class loses real behavior; overriding all except one is complex; no spy means no partial mocking.
  4. Final Answer:

    Create a spy of PaymentProcessor and stub only processPayment() method with Mockito.doReturn(). -> Option D
  5. Quick Check:

    @Spy + stub target method = partial mocking [OK]
Hint: Spy real object, stub only target method for partial mocking [OK]
Common Mistakes:
  • Mocking entire class losing real method calls
  • Overriding too many methods manually
  • Not using @Spy for partial mocking
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard