คำตอบแบบกำหนดเองและโคลแบ็ก

Sometimes, simply returning a fixed value with when().thenReturn() isn't enough for your mock objects.

• What if a mock method needs to modify an argument passed to it?
• What if it needs to execute a callback function?
• What if its return value depends on multiple inputs in a complex, dynamic way?

These advanced scenarios call for custom logic within your mocks.

Mockito provides the org.mockito.stubbing.Answer interface. This powerful tool lets you define custom behavior for a mocked method call.

• Think of it as writing a small piece of code that runs whenever the mocked method is invoked.
• The Answer interface has a single method: Object answer(Invocation invocation) throws Throwable;.

It gives you fine-grained control over mock responses.

The answer() method is where you implement your custom logic. It receives an InvocationOnMock object (often just referred to as invocation).

• The InvocationOnMock object provides crucial details about the method call:
  • Which method was called?
  • What arguments were passed?
  • Which mock object was involved?

You can use these details to decide what to return, throw an exception, or perform side effects.

While you can use when().thenAnswer(), Mockito's doAnswer() method is often more flexible and widely used, especially for void methods or when combining with other stubbings.

• doAnswer() allows you to specify behavior for a method call before defining when().
• It's particularly useful when you need to:
  • Capture arguments.
  • Invoke callbacks.
  • Change the state of objects passed as arguments.

Let's see how to use doAnswer to return a value that depends on the input argument. Here, our mock will double the input number.

A very common and powerful use case for doAnswer is simulating asynchronous operations or invoking callbacks.

• Imagine a service that takes a Callback interface (e.g., a Consumer) as an argument.
• You can use doAnswer to manually invoke the onSuccess or onFailure method of that callback.

This allows you to test how your application code reacts to different callback outcomes without actual asynchronous execution.

Here, we simulate a DataService calling a Consumer callback. doAnswer lets us trigger the callback with a specific value when fetchData is called.

The InvocationOnMock object (or simply invocation) passed to your answer() method is a powerful context object.

• invocation.getArguments(): Returns an array of all arguments passed to the mocked method.
• invocation.getArgument(index): Returns a specific argument by its index.
• invocation.getMethod(): Gives you the Method object that was called, allowing reflection.
• invocation.getMock(): Returns the mock object itself.
• invocation.callRealMethod(): For spies, this allows invoking the actual, real method.

Custom answers are powerful, but it's important to use them thoughtfully to keep your tests maintainable and clear:

• Keep them simple: If your answer logic becomes too complex, it might indicate a design issue in your production code or an overly complicated test setup.
• Prefer simpler stubbing: Always choose simpler stubbing methods like thenReturn(), thenThrow(), or thenCallRealMethod() if they can achieve the desired behavior.
• Test the Answer itself: For very complex Answer implementations, consider extracting them into a separate class and writing a unit test for that class.

Here are typical situations where the Answer interface (usually via doAnswer()) truly shines:

• Dynamic return values: When the return value depends on input arguments in a non-trivial or calculated way.
• Side effects: Modifying arguments that are passed by reference (e.g., updating an object).
• Callbacks: Triggering success or failure callbacks to simulate asynchronous operations.
• Chaining operations: Simulating a sequence of interactions or state changes within a single mock call.

You are testing a UserService that depends on a UserRepository. The UserRepository has a method save(User user) which typically updates the user's ID after saving it to a database.

You want to mock UserRepository to simulate this behavior without hitting a real database. Assume a User class with setId(Long id).

You've learned how to bring dynamic and complex behavior to your mocks using Mockito's Answer interface and the doAnswer method.

• The Answer interface lets you define custom logic that executes when a mocked method is called.
• The InvocationOnMock object provides essential context, including method arguments and the mock itself.
• doAnswer is ideal for dynamic return values, simulating callbacks, or modifying arguments passed by reference.

Remember to use `Answer` judiciously, preferring simpler stubbing when possible, to keep your tests clear and focused.