Benutzerdefinierte Antworten und Callbacks
Implementieren Sie benutzerdefinierte Logik für Aufrufe von Mock-Methoden, indem Sie `Answer`-Schnittstellen verwenden, um komplexe Verhaltensweisen zu simulieren.
Benutzerdefinierte Antworten und Callbacks ist eine kostenlose Testing Mastery: JUnit, Mockito & Integration Tests-Lektion auf CoddyKit. Dies ist Lektion 1 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Testing Mastery: JUnit, Mockito & Integration Tests-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Testing Mastery: JUnit, Mockito & Integration Tests-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
Beyond Simple Stubbing
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.
Introducing Mockito's Answer
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
Answerinterface has a single method:Object answer(Invocation invocation) throws Throwable;.
It gives you fine-grained control over mock responses.
Anatomy of answer()
The answer() method is where you implement your custom logic. It receives an InvocationOnMock object (often just referred to as invocation).
- The
InvocationOnMockobject 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.
Using doAnswer for Flexibility
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 definingwhen().- It's particularly useful when you need to:
- Capture arguments.
- Invoke callbacks.
- Change the state of objects passed as arguments.
Custom Return Logic
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.
import org.mockito.Mockito;
import org.mockito.invocation.InvocationOnMock;
import org.mockito.stubbing.Answer;
// A simple interface to mock
interface Calculator {
int calculate(int input);
}
public class Main {
public static void main(String[] args) {
// Create a mock object for our Calculator interface
Calculator mockCalculator = Mockito.mock(Calculator.class);
// Define custom answer to double the input argument
Mockito.doAnswer(new Answer<Integer>() {
@Override
public Integer answer(InvocationOnMock invocation) throws Throwable {
// Get the first argument (index 0) as an Integer
Integer arg = invocation.getArgument(0);
return arg * 2; // Return double the argument
}
}).when(mockCalculator).calculate(Mockito.anyInt()); // Apply to any int input
// Test the custom behavior of the mock
System.out.println("Result for 5: " + mockCalculator.calculate(5));
System.out.println("Result for 10: " + mockCalculator.calculate(10));
}
}Simulating Callbacks
A very common and powerful use case for doAnswer is simulating asynchronous operations or invoking callbacks.
- Imagine a service that takes a
Callbackinterface (e.g., aConsumer) as an argument. - You can use
doAnswerto manually invoke theonSuccessoronFailuremethod of that callback.
This allows you to test how your application code reacts to different callback outcomes without actual asynchronous execution.
Mocking a Callback
Here, we simulate a DataService calling a Consumer callback. doAnswer lets us trigger the callback with a specific value when fetchData is called.
import org.mockito.Mockito;
import org.mockito.invocation.InvocationOnMock;
import org.mockito.stubbing.Answer;
import java.util.function.Consumer;
// An interface representing a service that fetches data asynchronously
interface DataService {
void fetchData(String query, Consumer<String> callback);
}
public class Main {
public static void main(String[] args) {
DataService mockService = Mockito.mock(DataService.class);
// Configure the mock to simulate fetching data and calling the callback
Mockito.doAnswer(new Answer<Void>() {
@Override
public Void answer(InvocationOnMock invocation) throws Throwable {
// Get the arguments passed to fetchData
String query = invocation.getArgument(0); // The first argument is the query
Consumer<String> callback = invocation.getArgument(1); // The second is the callback
// Simulate a successful data fetch by invoking the callback
callback.accept("Data for '" + query + "' fetched successfully!");
return null; // Void methods in doAnswer return null
}
}).when(mockService).fetchData(Mockito.anyString(), Mockito.any(Consumer.class));
// Our application code would typically use this service
System.out.println("Application requesting user data...");
mockService.fetchData("user:456", result -> {
System.out.println("Application received data: " + result);
});
System.out.println("Application finished request setup.");
}
}Deeper with Invocation
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 theMethodobject that was called, allowing reflection.invocation.getMock(): Returns the mock object itself.invocation.callRealMethod(): For spies, this allows invoking the actual, real method.
Tips for Answer Use
Custom answers are powerful, but it's important to use them thoughtfully to keep your tests maintainable and clear:
- Keep them simple: If your
answerlogic 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(), orthenCallRealMethod()if they can achieve the desired behavior. - Test the
Answeritself: For very complexAnswerimplementations, consider extracting them into a separate class and writing a unit test for that class.
When to Use Answer
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.
Custom Mock Behavior
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).
Recap: Dynamic Mocks
You've learned how to bring dynamic and complex behavior to your mocks using Mockito's Answer interface and the doAnswer method.
- The
Answerinterface lets you define custom logic that executes when a mocked method is called. - The
InvocationOnMockobject provides essential context, including method arguments and the mock itself. doAnsweris 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.
Häufig gestellte Fragen
Ist die Lektion „Benutzerdefinierte Antworten und Callbacks“ kostenlos?
Ja — der vollständige Text von „Benutzerdefinierte Antworten und Callbacks“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Testing Mastery: JUnit, Mockito & Integration Tests-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Testing Mastery: JUnit, Mockito & Integration Tests-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Benutzerdefinierte Antworten und Callbacks“?
Implementieren Sie benutzerdefinierte Logik für Aufrufe von Mock-Methoden, indem Sie `Answer`-Schnittstellen verwenden, um komplexe Verhaltensweisen zu simulieren. Du übst Testing Mastery: JUnit, Mockito & Integration Tests mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um Testing Mastery: JUnit, Mockito & Integration Tests zu starten?
Keine Vorkenntnisse erforderlich. Testing Mastery: JUnit, Mockito & Integration Tests auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 1 von 4.
Wie lange dauert die Lektion „Benutzerdefinierte Antworten und Callbacks“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser Testing Mastery: JUnit, Mockito & Integration Tests-Lektion Code schreiben und ausführen?
Ja. Jede Testing Mastery: JUnit, Mockito & Integration Tests-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Benutzerdefinierte Antworten und Callbacks
- Mocking statischer Methoden und Konstruktoren
- Best Practices für Mockito
- Argumente mit ArgumentCaptor erfassen