Why Mocking void methods in JUnit? - Purpose & Use Cases

The Big Idea

What if you could test actions that don't give answers back, without messy manual checks?

The Scenario

Imagine you have a method that just sends an email or logs a message but doesn't return anything. You want to test your code that calls this method, but since it doesn't give back a result, how do you check if it worked correctly?

The Problem

Manually testing such methods means you have to check external effects like email inboxes or log files. This is slow, unreliable, and hard to automate. You might miss errors or waste time repeating the same checks.

The Solution

Mocking void methods lets you replace these methods with fake versions that do nothing or track calls. This way, you can test your code's behavior without real side effects, making tests fast, reliable, and easy to write.

Before vs After

✗ Before

emailService.sendEmail(user, message);
// Manually check inbox or logs

✓ After

doNothing().when(emailService).sendEmail(any(), any());
verify(emailService).sendEmail(user, message);

What It Enables

It enables automated tests to confirm that important actions happened without causing real side effects.

Real Life Example

Testing that a notification is sent when a user signs up, without actually sending emails every time you run tests.

Key Takeaways

Void methods don't return values, making them tricky to test.

Manual checks are slow and error-prone.

Mocking void methods lets tests run fast and reliably by simulating behavior.

Practice

1. What is the main purpose of mocking void methods in JUnit tests?

easy

A. To convert void methods into methods that return values

B. To control their behavior and verify interactions without executing actual code

C. To automatically generate return values for void methods

D. To disable all tests that call void methods

Solution

1. Step 1: Understand void methods in tests

   Void methods do not return values, so mocking helps control their side effects during tests.

2. Step 2: Purpose of mocking void methods

   Mocking allows skipping actual execution and verifying if the method was called, without running real code.

3. Final Answer:

   To control their behavior and verify interactions without executing actual code -> Option B

4. Quick Check:

   Mock void methods = control behavior + verify calls [OK]

Hint: Mock void methods to control calls without running code [OK]

Common Mistakes:

• Thinking void methods return values
• Assuming mocking changes method return type
• Believing mocking disables all tests

2. Which Mockito syntax correctly mocks a void method sendEmail() to do nothing when called?

easy

A. doNothing().when(mock).sendEmail();

B. verify(mock).doNothing().sendEmail();

C. mock.sendEmail().doNothing();

D. when(mock.sendEmail()).thenReturn(null);

Solution

1. Step 1: Recall Mockito syntax for void methods

   Mockito uses doNothing().when(mock).method() to mock void methods doing nothing.

2. Step 2: Analyze options

   doNothing().when(mock).sendEmail(); matches correct syntax; others misuse when() or verify().

3. Final Answer:

   doNothing().when(mock).sendEmail(); -> Option A

4. Quick Check:

   Mock void method to do nothing = doNothing().when() [OK]

Hint: Use doNothing().when(mock).voidMethod() to mock void methods [OK]

Common Mistakes:

• Using when() with void methods incorrectly
• Trying to chain doNothing() after method call
• Confusing verify() with mocking syntax

3. Given the code snippet:

doThrow(new RuntimeException()).when(mock).deleteFile();
mock.deleteFile();

What happens when mock.deleteFile() is called?

medium

A. The test fails to compile

B. The method executes normally without exception

C. The method returns null

D. A RuntimeException is thrown

Solution

1. Step 1: Understand doThrow() usage

   doThrow() tells Mockito to throw the specified exception when the void method is called.

2. Step 2: Analyze method call effect

   Calling mock.deleteFile() triggers the RuntimeException as mocked.

3. Final Answer:

   A RuntimeException is thrown -> Option D

4. Quick Check:

   doThrow() causes exception on void method call [OK]

Hint: doThrow() makes void method throw exception when called [OK]

Common Mistakes:

• Expecting method to run normally
• Thinking void methods return null
• Confusing doThrow() with doNothing()

4. Identify the error in this Mockito code snippet:

doNothing().when(mock.deleteFile());

medium

A. Incorrect use of when() with method call inside

B. Missing exception type in doNothing()

C. doNothing() cannot be used with void methods

D. No error, code is correct

Solution

1. Step 1: Check Mockito syntax for mocking void methods

   Correct syntax is doNothing().when(mock).method(), not passing method call inside when().

2. Step 2: Identify error in code

   Code incorrectly calls method inside when(), causing syntax error.

3. Final Answer:

   Incorrect use of when() with method call inside -> Option A

4. Quick Check:

   when() expects mock object, not method call [OK]

Hint: Use when(mock).method(), not when(method()) [OK]

Common Mistakes:

• Calling method inside when() instead of after when(mock)
• Thinking doNothing() needs exception type
• Believing doNothing() can't mock void methods

5. You want to verify that a void method logAction() was called exactly twice during a test. Which Mockito code correctly does this?

hard

A. verify(mock).logAction(times(2));

B. doNothing().when(mock).logAction(); verify(mock).logAction();

C. verify(mock, times(2)).logAction();

D. when(mock.logAction()).thenReturn(2);

Solution

1. Step 1: Recall Mockito verify syntax for call count

   Use verify(mock, times(n)).method() to check method called n times.

2. Step 2: Analyze options

   verify(mock, times(2)).logAction(); uses correct syntax; others misuse verify or when with void methods.

3. Final Answer:

   verify(mock, times(2)).logAction(); -> Option C

4. Quick Check:

   Verify call count = verify(mock, times(n)) [OK]

Hint: Use verify(mock, times(n)) to check void method call count [OK]

Common Mistakes:

• Using when() with void methods to check calls
• Misplacing times() inside method call
• Not specifying times() for multiple calls