Ullrich: Die Seite wurde neu angelegt: „Category:Java Category:Mockito = Einführung = Ein Mock – im Sinne dieser Eiführung – ist ein Objekt, das so aussieht aber sich nicht so verhält…“

2021-04-21T19:23:50Z

Die Seite wurde neu angelegt: „Category:Java Category:Mockito = Einführung = Ein Mock – im Sinne dieser Eiführung – ist ein Objekt, das so aussieht aber sich nicht so verhält…“

Neue Seite

[[Category:Java]]
[[Category:Mockito]]
= Einführung =
Ein Mock – im Sinne dieser Eiführung – ist ein Objekt, das so aussieht aber sich nicht so verhält wie das "echte" Objekt das es ersetzt.
Man kann sich das vorstellen wie eine Theater-Requisite: Benötigt man auf der Bühne ein Buch, verwendet man einen Pappkarton,
der von außen aussieht wie ein Buch aber keines ist. So versteht diese Einführung unter einem "Mock" -- salopp ausgedrückt:
{{Quotation|
ein Objekt, das ein anderes ersetzt und dabei das originale Objekt in bestimmten Aspekten nachahmen kann,

aber niemals dessen vollständige Funtionalität hat.
Es kann Funktionalität und Seiteneffekte hinzufügen falls erforderlich.}}

Tatsächlich ist die Verwendung der Begriffe Dummy, Fake, Stub und Mock durchaus uneinheitlich.
Für diese Einführung verzichten wir auf eine akademische Unterscheidung, gehen pragmatisch vor,
sprechen durchgehend vom "Mock" und meinen das oben genannte.
Dem Sprachenthusiasten, der an einer genaueren Definition interessiert ist,
sei zum Einstieg der Blog-Artikel von
[https://martinfowler.com/articles/mocksArentStubs.html Martin Fowler] empfohlen.

== Aufgaben ==
Ein Mock kann bei der Implementierung von Unit-Tests für verschiedene Aufgaben genutzt werden.
Man kann diese Aufgaben in der Regel auch anders lösen, aber wir möchten hier natürlich erörtern
wie ''Mockito'' uns bei der Erfüllung unterstützen kann.

Typische Aufgaben für Mocks sind
*Das Emulieren von Klassen, deren wahre Funktionalität nicht ausgeführt werden kann, darf oder soll
*Das Erzeugen von Instanzen von Interfaces und Klassen, von denen keine konkrete Implementierung erzeugt werden kann
*Der Überprüfung, ob –- und mit welchen Argumenten -– Methoden einer Klasse aufgerufen wurden.

'''So tun als täte es:''' Jeder Unit-Test muß isoliert und ohne externe Abhängigkeiten ausgeführt werden können. Es
reicht nicht, wenn der Test lokal im Eclipse läuft, er muß auch jederzeit vom Jenkins-Build ausgeführt werden
können. Greift beispielsweise eine Methode auf einen Web-Service oder eine lokale Datenbank zu, kann der Test
nicht ausgeführt werden. Man kann dann Mock-Implementierungen der Service-Klasse bzw. der Persistenz-Schicht
erzeugen und mit diesen als Ersatz den Unit-Test durchführen.

'''So tun als gäbe es:''' Der Typ eines Parameters der zu testenden Methode sei ein Interface. Dann benötigt man
für den Aufruf der Methode im Rahmen des Unit-Tests eine Objekt-Instanz einer Klasse die das Interface implementiert.
Statt das Interface selbst zu implementieren, überläßt man Mockito die Fußarbeit und nutzt einen Mock.

'''Prüfen, ob:''' In vielen Unit-Tests möchte man sicherstellen, daß beim Durchlauf eine bestimmte Methode
aufgerufen wird (oder garantiert nicht aufgerufen wird) oder daß eine Methode mit bestimmten Argumenten aufgerufen wird.
Das läßt sich bei allen Mockito-Mocks serienmäßig überprüfen, Mockito erlaubt es aber auch, "echte" Objekte
mit einem Spy-Objekt zu umwickeln über das die entsprechende Information abgerufen werden kann.

== Abgrenzung ==
Anstelle von Mockito-Mocks kann man auch einfach
Interfaces implementieren und Klassen ableiten um zu Mock-Implementierungen zu kommen. Java-Interfaces
wurden ja auch zu dem Zweck geschaffen, unterschiedlicher Implementierungen mit der gleichen Schnittstelle zu
schaffen – warum also Mockito nutzen? Die Erzeugung eines Mockito-Mocks nimmt eine Zeile Code in Anspruch;
gleichgültig wieviele Methoden implementiert oder überschrieben werden. Eine konkrete Klasse braucht eine
explizite Implementierung und das wird schnell unübersichtlich. Zudem aktualisiert sich der Mock automatisch,
weil er erst zur Laufzeit entsteht. Eine händische Implementierung eines Interface muß jedesmal angefaßt werden,
wenn sich das Interface ändert – ein Mockito-Mock nicht.

Zum Schluß der Einleitung sei darauf hingewiesen, was Mockito nicht mocken kann:
*statische Methoden
*private Methoden
*finale Klassen und Methoden

Auf dieser Seite geht es um die Erstellung von Mocks. Spies und alternative Vorgehen werden [[Partieller Mock|hier]]
behandelt, um das Überprüfen des Aufrufverhaltens [[Mockito Verify|hier]].

= Mocking =
Mocking hat zwei Schritte. Zunächst wird ein Mock-Objekt von der gewünschten Klasse erzeugt,
dann werden Methoden des Objekts in der Weise implementiert wie es für den Test erforderlich ist.

Der zweite Schritt ist optional, ein vollständig funktionsloser Mock ist in vielen Fällen schon
ausreichend. In aller Regel wird man dem Mock jedoch Funktionalität hinzufügen wollen.
Diese Einführung folgt diesem Vorgehen und beschreibt die nötigen Werkzeuge. Alternative
Ansätze werden hier [[Partieller_Mock|besprochen]].

== Das Mock-Objekt ==

Der einfachste Mock für ein Objekte einer Klasse oder eines Interfaces erlaubt den Aufruf jeder nicht-statischen,
non-private, non-final Methode ohne daß dabei eine Exception auftritt.
Er wird so erzeugt:
{{java|code=Foo mock = Mockito.mock(Foo.class);}}
Die Methoden des Mocks tun nichts, sie rufen auch keine super-Methoden auf. Es wird nur sichergestellt daß jede Methode
gefahrlos aufgerufen werden kann und ggf. einen gültigen, wenn auch bedeutungslosen Wert liefert. Anstelle von Objekten
(dazu gehören auch Strings) erhält man stets {{java|null}}, numerische Ergebnisse sind immer ''0''
und boolean-Methoden liefern immer {{java|false}}.

Wird eine Klasse gemockt, erzeugt Mockito eine Ableitung der zu mockenden Klasse. In der Folge können weder finale
Klassen noch finale Methoden gemockt werden. Gleiches gilt für statische Methoden, die nicht vererbt werden.

Der Mock kann auf Felder der gemockten Klasse zugreifen, solange diese nicht private sind. Allerdings kann
er keine eigenen Felder definieren. Auf public und package visible Felder kann auch von außen zugegriffen werden.

== Mocken von Methoden ==

Wie erwähnt, liefern Methoden gemockter Klassen nur default-Werte; das ist selten ausreichend.
Betrachten wir zunächst die einfachste Variante:
bei jedem Aufruf der Methode solleb die gleichen, feste Werte geliefert werden.
Wir mocken dafür das folgende Interface:
{{java|code=
public interface Person {
String id();
String abteilung();
int foo(String dings);
}
}}
=== Parameterlose Methoden ===
Soll etwa die ID der Person immer den Wert 5 liefern, könnte das so aussehen:
{{java|code=
person = Mockito.mock(Person.class);
Mockito.when(person.id()).thenReturn(5);
}}
Das Argument der {{java|when}}-Methode ist ein Methoden-Aufruf auf den Mock,
das Argument der {{java|thenReturn}}-Methode ist der zu liefernde Wert.
Soll die Methode eine Abfolge fester Werte liefern, kann man eine Liste angeben:
{{java|code=Mockito.when(person.abteilung()).thenReturn("BLA", "FOO");}}
Beim ersten Aufruf liefert die Methode den String {{java|BLA}} und beim zweiten {{java|FOO}}.
Man kann die Werte auch einzeln angeben:
{{java|code=
Mockito.when(person.abteilung())
.thenReturn("BLA")
.thenReturn("FOO");
}}
Verwendet man die zweite Variante, kann man die gemockte Methode auch dazu bringen, zwischendurch Exceptions zu werfen:
{{java|code=
Mockito.when(person.abteilung())
.thenReturn("BLA")
.thenThrow(new RuntimeException());
.thenReturn("FOO");
}}
Sind alle Werte durch Aufruf verbraucht, liefert die Methode wieder den default-Wert.

=== Methoden mit Parametern ===
Die meisten Methoden haben einen oder mehrere Parameter. Will man solche Methoden mocken, muß man
spezifizieren bei welchen Argumenten welche Ergebnisse geliefert werden sollen. Im einfachsten Falle gibt man den
Argument-Wert als Literal vor:
{{java|code=
Foo p = Mockito.mock(Person.class);
Mockito.when(p.foo("x")).thenReturn(10);
Assertions.assertThat(p.foo("x")).isEqualTo(10);
}}
Die Methode {{java|foo}} liefert für {{java|foo("X")}} nun den Wert ''10'' und für alle anderen Argumente einen undefinierten Wert.
Wie erwähnt wird die Methode für alle anderen Argumente den Wert ''0'' liefern, aber man sollte sich nicht darauf verlassen,
daß das auch immer und unter allen Umständen so sein wird.

In den meisten Fällen wird man nicht auf einzelne Werte reagieren wollen, sondern auf Gruppen von Werten oder
auf alle möglichen Werte. Um das zu bewerkstelligen werden Matcher benötigt, die beim Aufruf versuchen die Argumente zu matchen.
Die Mockito-Matcher werden über statische Methoden der Klasse {{java|ArgumentMatchers}} bereitgestellt.

Da unsere Einstiegsklasse {{java|Mockito}} davon ableitet, "erbt" sie alle dort beheimateten statischen Methodem. Der Kürze halber
wird man sie also –- wie hier dargestellt –- über die Mockito-Klasse referenzieren. Das ist nach der reinen Java-Lehre eigentlich
nicht sauber, da statische Methoden nicht vererbbar sind. Aber da hier keine Probleme zu erwaretn sind, darf der Test-Code sich das erlauben.

Im Folgenden werden einige häufig benutzte Matcher vorgestellt.

==== Immer das Gleiche ====
Um für ''jedes'' beliebige Argument den gleichen Wert zuliefern, verwendet man einen der vielen {{java|any}}-Matcher.
{{java|Mockito.anyString()}} etwa akzeptiert jeden String mit Ausnahme von {{java|null}} -- dazu später:
{{java|code=Mockito.when(p.foo(Mockito.anyString())).thenReturn(12);}}
Die Methode {{java|foo}} liefert nun für jedes beliebige String-Argument – ganz verläßlich – den Wert ''12''.
Analog zu String bietet Mockito für eine Vielzahl von Typen – darunter auch für alle simplen Typen
wie {{java|int}} oder {{java|boolean}} – Matcher an, die jeweils mit "any" beginnen.
Kann der Compiler den Typ selbst erkennen, geht auch das generische {{java|any()}}:
{{java|code=Mockito.when(p.foo(Mockito.any())).thenReturn(10);}}
Handelt es sich um eine Klasse, kann man den Typ auch explizit angeben:
{{java|code=Mockito.when(p.foo(Mockito.any(String.class))).thenReturn(10);}}
Soll neben echten Objekten auch {{java|null}} als Argument akzeptiert werden, verwendet man {{java|nullable}};
das geht nur unter Angabe einer Klasse:
{{java|code=Mockito.when(p.foo(Mockito.nullabe(String.class))).thenReturn(10);}}
Möchte man ''nur'' auf {{java|null}} reagieren geht das auch, diesmal ohne Klasse:
{{java|code=Mockito.when(p.foo(Mockito.isNull())).thenReturn(10);}}

==== Manchmal das Gleiche ====
Das Konstrukt {{java|Mockito.anyString()}} liefert einen Matcher. Das ist ein Objekt, das beim Aufruf den Eingabe-Wert
analysiert und Übereinstimmungen signalisiert. Erkennt der Matcher im {{java|when()}}-Teil das definierte Muster,
wird der Wert des {{java|thenReturn()}} als Ergebnis geliefert.

Neben den any-Matchern giebt es eine Fülle anderer Matcher die auf verschiedene Auswahlen von Argumenten passen.
Zum Gebrauch sei auf die API-Doku von {{java|ArgumentMatchers}} verwiesen.

Die meisten Fälle lassen sich aber mit dem Universal-Matcher {{java|argThat}} behandeln. Er verlangt als Argument
eine Implementierung des (funktionalen) Interfaces {{java|ArgumentMatcher <T>}} ('''ohne -s!''').
Das Interface ist äquivalent zum JDK-Interface {{java|Predicate}}, es hat einen Objekt-Parameter und liefert
{{java|true}} für "Match" oder {{java|false}} oder "kein Match".
Dadurch läßt sich jeder passende {{lambda}}-Ausdruck als Matcher verwenden.
In voller {{lambda}}-Geschwätzigkeit sieht das zum Beispiel so aus:
{{java|code=Mockito.when(p.foo(ArgumentMatchers.argThat((String s) -> s.length() > 5))).thenReturn(10);}}
Wenn das das alles nicht reicht, findet man in der hamcrest-Bibliothek eine unglaubliche Fülle weiterer Matcher.

==== Mal dies -- mal das ====
Man kann beliebig viele {{java|.when}}-Konstrukte verwenden um den Mock für unterschiedlichen Argumente
unterschiedliche Ergebnisse liefern zu lassen. Mockito wendet die Matcher bei der späteren Ausführung in der
'''umgekehrten''' Reihenfolge ihrer Definition an. In der folgenden Kombination
{{java|code=
Foo p = Mockito.mock(Foo.class);
Mockito.when(p.foo(Mockito.anyString())).thenReturn(12);
Mockito.when(p.foo("x")).thenReturn(10);
}}
liefert {{java|foo("x")}} daher den Wert ''10'' und für jedes andere Argument liefert {{java|foo}} den Wert ''12''.
Selbstverständlich lassen sich in jedem Ausdruck beliebige Matcher verwenden.
Man muß bei der Definition aber darauf achten, daß die allgemeineren Matcher zuerst kommen.
Fügt man dem letzten Beispiel etwa noch ein {{java|.when}} mit einem {{java|anyString()}} an:
{{java|code=Mockito.when(Mockito.anyString()).thenReturn(4711);}}
dann werden alle vorher definierten Regeln ignoriert weil die letzte und allgemeinste Regel zuerst zieht.

=== Methoden responsive mocken ===
Die oben vorgestellten Verfahren liefern bei jedem Methoden-Aufruf feste Werte die bei der Mock-Definition festgelegt werden.
Oft ist es aber erforderlich, daß bei Aufruf der gemockten Methode Werte zurückgeliefert die aus den Argumenten errechnet werden.
Oder es ist erforderlich, daß die gemockte Methode irgendwelche Aktivitäten ausführt.

Mit den genannten Verfahren ist das nicht möglich, man benötigt eine "Answer". Dazu stehen zwei Varianten
zur Verfügung die sich in der Reihenfolge der Definition unterscheiden. Welche Variante man bevorzugt ist in vielen
Fällen unerheblich, when ... thenAnswer ist vielleicht etwas "intuitiver". Keine Wahl hat man, wenn man eine
void-Methode mocken möchte. Auch beim Mocken einzelner Methoden eines [[Partieller_Mock|Spys]] muß man die zweite Variante verwenden.
Als Beispiel sei für das Interface
{{java|code=
public interface Transform {
String calc(int value);
}
}}
ein Mock definiert durch:
{{java|code=Transform trans = Mockito.mock(Transform.class);}}

Um das Verhalten der Methode {{java|calc}} zu definieren bauen wir ein Objekt vom Typ {{java|Answer<T>}}.
Der Typ {{java|T}} wird ersetzt durch den Ergebnis-Typ der zu mockenden Methode -- in diesem Falle {{java|String}}.

Das {{java|Answer<T>}}-Objekt muß eine Methode überschreiben die ein Objekt der Klasse {{java|InvocationOnMock}}
als Argument nimmt. Über dieses Objekt erhalten wir Informtionen zu den Argumenten beim Aufruf der Mock-Methode.
Wir können sie mit der Methode {{java|getArgument}} über ihren Index abrufen, der Index beginnt bei 0.
Für die weiteren Methoden der Klasse sei auf die API-Dokumentation verwiesen.

Betrachten wir dazu eine konkrete Implementierung.

==== when ... thenAnswer ====
Die erste Variante nennt ''erst'' den Mock und ''dann'' die zu mockende Methode:
{{java|code=
Mockito.when(trans.calc(Mockito.anyString())).thenAnswer(new Answer<String>() {
@Override
public String answer(InvocationOnMock invocation) throws Throwable {
Integer value = invocation.getArgument(0);
return value.toString();
}
});
}}
Mit Java-8 läßt sich die anonyme Klasse auch eleganter mit einem {{lambda}}-Ausdruck schreiben:
{{java|code=
Mockito.when(trans.calc(Mockito.anyString())).thenAnswer(
(Answer<String>) invocation -> {
Integer value = invocation.getArgument(0);
return value.toUpperCase();
}
);
}}
Der Ergebnis-Typ von {{java|getArgument}} wird hier durch die Variable bestimmt der das Ergebnis zugewiesen wird.
Ob die Argument-Typen tatsächlich übereinstimmen, kann Java zur Compile-Zeit leider nicht kontrollieren.
Der Entwickler muß also selber darauf achten, daß alle Typen korrekt angegeben werden.

Im Gegensatz zur anonymen-Klasse-Variante kann im {{lambda}}-Ausdruck der Ergebnis-Typ {{java|Answer<String>}}
weggelassen werden. Man sollte ihn aber trotzdem hinschreiben, damit der Typ dokumentiert ist – man tut sich damit
bei der Fehlersuche erheblich leichter.

In den obigen Beispielen werden die Argumente vor Gebrauch in lokale Variablen abgefüllt, bevor diese im return-Ausdruck
verwendet werden. Das ist in der Regel nicht erforderlich, man kann die Typen von der Java-Magie bestimmern lassen.
Die geschwätzige Variante mit den lokalen Variablen hat aber den Vorteil, daß die Typen auf den ersten Blick zu erkennen
sind. Werden schrecklich Methoden mit vielen Parametern aufgerufen, wird das schnell zum Geduldspiel.

==== doAnswer ... when ====
Bei dieser Variante wird ''erst'' die Answer definiert und ''hinterher'' der Mock und die aufzurufende Methode.
Auch hier gewinnt der Aufruf durch die Verwendung von {{lambda}}-Ausdrücken durchaus an Lesbarkeit --
wir lassen die konventionelle Variante diesmal weg:
{{java|code=
Mockito.doAnswer(
(Answer<String>) invocation -> {
Integer value = invocation.getArgument(0);
return value.toString();
}
).when(trans.calc(Mockito.anyString()));
}}
Das Konstrukt funktioniert genauso wie das im vorangegangenen Abschnitt beschrieben.

Allerdings kann man den Aufruf auch subtil anders gestalten (hier wird nur die {{lambda}}-Variante wiedergegeben):
{{java|code=
Mockito.doAnswer(
(Answer<String>) invocation -> {
Integer value = invocation.getArgument(0);
return value.toString();
}
).when(trans).calc(Mockito.anyString());
}}
Der Unterschied liegt in der letzten Zeile. Im ersten Falle wird {{java|.when()}} mit dem Mock der gemockten ''Methode'' aufgerufen.
Im zweiten Falle wird {{java|.when()}} mit dem Mock der gemockten ''Klasse'' aufgerufen. Die zweite Variante macht das
Mocking von void-Methoden möglich und erlaubt, einzelne Methoden von Spy-Objekten zu mocken und damit [[Partieller Mock|partielle Mocks]] zu erzeugen.

=== void-Methoden: Methoden ohne Ergebnis ===
Eine void-Methode ist eine Methode, die kein Ergebnis liefert – was sollte man hier mocken?
Betrachten wir dazu folgendes Beispiel:
{{java|code=
public class CustomerManager {
public void save(Customer customer) {
getDatabaseLink().merge(customer);
}
}
}}
Die {{java|save}}-Methode nimmt als Parameter ein Entity und persistiert dessen Inhalt in der Datenbank.
Das ist etwas, was wir im Unit-Test normalerweise nicht tun möchten. Wir würden stattdessen
den vielleicht den Aufruf protokollieren oder die Persistierung in einem Java-Objekt emulieren.

Beim Mocking geht es also darum, beim Ausführen der gemockten void-Methode einen Seiteneffekt herbeizuführen.
Wie bereits beschrieben, giebt es prinzipiell zwei Muster nach denen sich in Mockito Methoden-Verhalten
implementieren läßt. Im Falle von void-Methoden fällt das when...then-Pattern jedoch aus, da die
Methode {{java|Mockito.when()}} keine void-Methoden verdauen kann.

Wir erzeugen also erstmal einen Mock:
{{java|code=Transform mock = Mockito.mock(CustomerManager.class);}}
und definieren die Antwort so:
{{java|code=
Mockito.doAnswer(new Answer<Void>() {
@Override
public Void answer(InvocationOnMock invocation) throws Throwable {
// Seiteneffekt
return null;
}
}).when(mock).save(Mockito.any(Customer.class));
}}
Der Trick ist die Verwendung der – übrigens schon seit JDK 1.1 existierenden – Klasse {{java|Void}}(mit großem Vau).
Zu jedem primitiven Typ gibt es in Java eine passende Wrapper-Klasse; ein Analogon hat der Ergebnis-Typ {{java|void}} in der
{{java|Void}}-Klasse. Da es keine {{java|void}}-Werte giebt, giebt es auch keine Instanzen der {{java|Void}}-Klasse;
die Klasse selbst gibt es aber und hier finden wir eine Gelegenheit sie zu nutzen: wir definieren damit den Ergebnis-Typ
der Answer-Methode.

Da {{java|Void}} – im Gegensatz zu {{java|void}} – eine Klasse ist, muß die {{java|answer}}-Methode ein Ergebnis liefern und
benötigt daher am Ende die Anweisung {{java|return null}}.

Natürlich läßt sich das auch mit einem {{lambda}}-Ausdruck schreiben:
{{java|code=
Mockito.doAnswer((Answer<Void>) invocation -> {
// Seiteneffekt
return null;
}).when(mock).save(Mockito.any(Customer .class));
}}

=== Methoden mit Variablen Argument-Listen ===
Weichen wir mal der Diskussion aus, ob Var-Arg-Methoden schön, sinnvoll oder wünschenswert sind und welche
Probleme sie mit sich bringen (könnten). Nehmen wir einfach an, wir hätten so ein Ding und ''müßten'' es mocken -- wie geht das?
Die Methode {{java|process}} akzeptiere eine beliebige Anzahl von {{java|Customer}}-Objekten, tue irgendwas damit und liefere
die Anzahl der verarbeiteten Objekte.
{{java|code=
public interface Transform {
int process(Customer... customer);
}
}}
Wie bereits beschrieben, können wir über ein Objekt der Klasse {{java|InvocationOnMock}} auf die Argumente zugreifen
die beim Aufruf der gemockten Methode übergeben werden. Die vararg-Argumente erhalten wir so als array und können z.B.
mit einer for-Schleife darüber iterieren. Versuchen wir es hier etwas hübscher aussehen zu lassen, indem wir das array in
eine typisierte Liste überführen.

Wir schreiben zunächst die Mock-Methode mit dem doAnswer...when-Pattern:
{{java|code=
void test() {
Mockito.doAnswer(new Answer<Integer>() {
@Override
public Integer answer(InvocationOnMock invocation) throws Throwable {
List<Customer> kunden = argliste(invocation.getArguments());
return kunden.size();
}
}).when(mock).process(Mockito.any());
}
}}
Und nun zur {{java|.argliste()}}-Methode, die das Object-array in ein {{java|List<Customer>}}-Objekt umwandelt. Es giebt
viele Möglichkeiten, die elegantesten arbeitet natürlich mit einem Stream. Das Delikate daran ist das erforderliche Casting, wir
verwenden dazu die .class-Klasse für die Customer-Klasse:
{{java|code=
List<Customer> argliste(Object liste[]) {
return Stream.of(liste)
.filter(Customer.class::isInstance)
.map(Customer.class::cast)
.collect(Collectors.toList());
}
}}
Was hierbei nicht offensichtlich ist, ist daß die {{java|arguments}}-Methode von {{java|InvocationOnMock}}
''alle'' Argumente liefert –- nicht nur die vararg-Argumente. Im folgenden Beispiel
{{java|int process(String beschreibung, Customer... customer);}}
liefert {{java|.arguments()[0]}} das Argument für den String-Parameter und erst ab {{java|.arguments()[1]}} kommen die vararg-Argumente.
Die obige Methode {{java|argliste}} funktioniert auch in diesem Falle unmittelbar, weil der nicht-variable Teil der ParameterListe
keine {{java|Customer}}-Objekte enthält. Das String-Argument wird einfach herausgefiltert.
Anders sieht es in diesem Beispiel aus:
{{java|code=int process(Customer referenz, String beschreibung, Customer... customer);}}
Offensichtlich soll das erste Customer-Objekt anders behandelt werden als die der vararg-Liste. Aber auch das geht
mit Streams ganz einfach. Wir müssen ja nur die ersten beiden Argumente bei der Verarbeitung überspringen; das
geht mit der {{java|.skip()}}-Methode:
{{java|code=
List<Customer> argliste(Object liste[]) {
return Stream.of(liste)
.skip(2)
.filter(Customer.class::isInstance)
.map(Customer.class::cast)
.collect(Collectors.toList());
}
}}
Und wenn wir die Methode noch öfter brauchen, können wir den start-Index (beginnend bei 0) und das verwendete
{{java|Class}}-Objekt noch parametrisieren:
{{java|code=
<T> List<T> argliste(Object liste[], int startIndex, Class<T> klasse) {
return Stream.of(liste)
.skip(startIndex)
.filter(klasse::isInstance)
.map(klasse::cast)
.collect(Collectors.toList());
}
}}
Diese letzte Variante können wir nun für das Mocking jeder Varag-Methode für jeden Varag-Typ verwenden.

== Abstrakte Klassen mocken ==
Der gemeine Mockito-Mock ersetzt alle Methoden der gemockten Klasse durch leere Mock-Aufrufe die –
defaultmäßig – gar nichts tun. Das kann man verhindern durch Angabe eines zusätzlichen Parameters:
{{java|code=MeineKlasse meinMock = mock(MeineKlasse.class, Mockito.CALLS_REAL_METHODS);}}

Wird jetzt eine Methode des Mocks aufgerufen, ruft dieser die originale Methode der Klasse {{java|MeineKlasse}} auf.
Anschließend kann man einzelne Methoden mocken und so einen partiellen Mock zu erzeugen.
Bei abstrakten Klassen tritt der Mock in's leere, sobald eine abstrakte Methode aufgerufen wird, weil es für diese
naturgemäß keine "echte" Methode giebt, die aufgerufen werden könnte. Um eine abstrakte Klasse so zu mocken,
daß genau die abstrakten Methoden gemockt werden, muß man also jede abstrakte Methode durch eine mock-Methode ersetzen – wie öde...
Mit der folgenden Klasse kann man das – Reflection sei dank – vollautomatisch erledigen lassen:
{{java|code=
import java.lang.reflect.Modifier;
...
public class MockerForAbstractMethods implements Answer<Object> {
@Override
public Object answer(InvocationOnMock invocation) throws Throwable {
if (Modifier.isAbstract(invocation.getMethod().getModifiers())) {
return Mockito.RETURNS_DEFAULTS.answer(invocation);
}
return Mockito.CALLS_REAL_METHODS.answer(invocation);
}
}
}}
Diese Klasse legt man an geeigneter Stelle ab, irgendwo im test-Ordner des Projekts. Die Anwendung im Unit-Tests
sieht dann so aus:
{{java|code=MeineKlasse meinMock = mock(MeineKlasse.class, new MockerForAbstractMethods());}}

Das Objekt prüft bei jedem Aufruf ob da eine abstrakte Methode aufgerufen wird und ersetzt den Aufruf durch einen
Mock-Aufruf. Ist die Methode nicht abstrakt, wird die "echte" Methode aufgerufen. Um das ganze in der Anwendung
etwas gefälliger zu machen, kann man die Instanz statisch erzeugen und eine Konstante dafür definieren:
{{java|code=public static final Answer<Object> MOCK_ABSTRACT_METHODS = new MockerForAbstractMethod();}}
Die Konstante kann man statisch importieren und dann schreiben:
{{java|code=MeineKlasse meinMock = mock(MeineKlasse.class, MOCK_ABSTRACT_METHODS);}}

Mockito: Einführung - Versionsgeschichte

Ullrich: Ullrich verschob die Seite Mockito Einführung nach Mockito: Einführung, ohne dabei eine Weiterleitung anzulegen

Ullrich am 23. Juni 2021 um 17:19 Uhr

Ullrich: /* Einführung */

Ullrich: Die Seite wurde neu angelegt: „Category:Java Category:Mockito = Einführung = Ein Mock – im Sinne dieser Eiführung – ist ein Objekt, das so aussieht aber sich nicht so verhält…“

← Nächstältere Version	Version vom 11. Januar 2024, 08:13 Uhr
(kein Unterschied)

← Nächstältere Version		Version vom 23. Juni 2021, 17:19 Uhr
Zeile 334:		Zeile 334:
	}).when(mock).save(Mockito.any(Customer .class));		}).when(mock).save(Mockito.any(Customer .class));
	}}		}}
			=== Methoden die Class-Objekte liefern ===
			Dieses Problem wird [[Mockito: Methoden die Class-Objekte liefern\|hier]] beschrieben
	=== Methoden mit Variablen Argument-Listen ===		=== Methoden mit Variablen Argument-Listen ===
	Weichen wir mal der Diskussion aus, ob Var-Arg-Methoden schön, sinnvoll oder wünschenswert sind und welche		Weichen wir mal der Diskussion aus, ob Var-Arg-Methoden schön, sinnvoll oder wünschenswert sind und welche

← Nächstältere Version		Version vom 21. April 2021, 19:28 Uhr
Zeile 2:		Zeile 2:
	[[Category:Mockito]]		[[Category:Mockito]]
	= Einführung =		= Einführung =
	Ein Mock – im Sinne dieser ~~Eiführung~~ – ist ein Objekt, das so aussieht aber sich nicht so verhält wie das "echte" Objekt das es ersetzt.		Ein Mock – im Sinne dieser Einführung – ist ein Objekt, das so aussieht aber sich nicht so verhält wie das "echte" Objekt das es ersetzt.
	Man kann sich das vorstellen wie eine Theater-Requisite: Benötigt man auf der Bühne ein Buch, verwendet man einen Pappkarton,		Man kann sich das vorstellen wie eine Theater-Requisite: Benötigt man auf der Bühne ein Buch, verwendet man einen Pappkarton,
	der von außen aussieht wie ein Buch aber keines ist. So versteht diese Einführung unter einem "Mock" -- salopp ausgedrückt:		der von außen aussieht wie ein Buch aber keines ist. So versteht diese Einführung unter einem "Mock" -- salopp ausgedrückt: