Erweiterte Tests mit Mockito

1.1 Mockito-Bibliothek

Heute machen wir uns mit fortgeschrittenen Tests vertraut. Genauer gesagt mit der Mockito -Bibliothek . Denken Sie nicht einmal daran, aus diesem Geschäft auszusteigen.

Erstens ist diese Bibliothek ein Standard im Frühjahrstest . Das ist eigentlich der Standard in der Java-Backend-Entwicklungsbranche.

Zweitens müssen Sie Tests für Ihren Spring-Code schreiben . Die einzige Möglichkeit zu verstehen, dass das von Ihnen geschriebene Backend ordnungsgemäß funktioniert, besteht darin, Methoden seiner API aufzurufen . Und es ist mit Tests zehnmal einfacher als ohne. Sie werden es selbst sehen.

pom.xmlSie können die Mockito-Bibliothek mit dem Code zu Ihrer hinzufügen :

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>4.2.0</version>
    <scope>test</scope>
</dependency>

Der gesamte Quellcode für das Mockito-Projekt ist auf GitHub zu finden .

1.2 Scheinobjekte

Was ist dieser Mockito und warum ist er so gut?

Im Verlauf der Entwicklung und Gestaltung von Tests bestand häufig die Notwendigkeit, anstelle eines realen Objekts eine Art „Stub“ in den Code einzufügen.

Beispielsweise wird der Code, der mit der Datenbank zusammenarbeitet, getestet und ändert dort etwas. Es ist gut, dass vor jedem Test der Zustand dieser Datenbank derselbe ist (sonst werden die Tests unterschiedlich sein). Und ich würde mir eine einfachere Basis wünschen, um diese Zustände schnell zurücksetzen zu können.

Oder Sie testen beispielsweise einen Code, der nützliche SMS versendet. Und für Direktmailings nutzt er eine Art kostenpflichtiges SMS-Gateway. Es wäre schön, ein virtuelles Gateway einzubauen, um den Code zu testen, um nicht Hunderte von SMS an unverständliche Personen zu senden.

Oder Ihr Code fordert Daten von anderen Webservern an, die auf dem Testserver einfach nicht verfügbar sind. Oder Sie schreiben einen Code für Online-Zahlungen, der 50 Mal getestet werden muss und erst dann in realen Finanzkanälen verwendet werden darf.

Ich denke, Sie verstehen ... Virtuelle Objekte, oder wie sie auch Stub-Objekte genannt werden, sind eine sehr nützliche Sache.

Und hier kommt die Schwierigkeit: Java verfügt über statische Typisierung. Das bedeutet, dass Sie die Klasse von erben müssen, um ReadDatabaseeiner Variablen statt einem Objekt vom Typ einen Verweis auf ein Objekt zuzuweisen .VirtualDatabaseVirtualDatabaseRealDatabase

Dann stellt sich heraus, dass die Klasse über RealDatabaseeine Reihe privater Methoden und Variablen verfügt, die Verweise auf andere reale Objekte speichern, und dass Sie auf diese Weise keinen normalen Stub schreiben können. In der Theorie ist es gut, aber in der Praxis ist es eine Sackgasse.

Und hier kommt die Rettung (Sie können DynamicProxymehr darüber lesen ), die bereits in Java 5 erschien. Sie ermöglicht die Erstellung virtueller Objekte, über die der Compiler keine Beschwerden hat.

Solche virtuellen Objekte werden Mocks genannt (vom Wort Mock – Layout). Die Mockito-Bibliothek konnte die Arbeit mit diesen Mocks auf ein beispielloses Niveau bringen. Daher übrigens auch der Name der Bibliothek.

1.3 @ExtendWith-Annotation

Die Mockito-Bibliothek funktioniert hervorragend mit JUnit, sie kann sogar als Erweiterung davon betrachtet werden.

Es gibt zwei Möglichkeiten, die Mockito-Bibliothek in Ihren Unit-Tests zu aktivieren. Die erste Möglichkeit besteht darin, eine spezielle Anmerkung hinzuzufügen:

@ExtendWith(MockitoExtension.class)
public class MockitoAnnotationTest {
    ...
}

Die zweite Möglichkeit besteht darin, seine Arbeit durch Aufrufen der Methode zu aktivieren openMocks():

public class MockitoAnnotationTest {
    @BeforeEach
    public void init() {
        MockitoAnnotations.openMocks(this);
   }
}

Meistens wird Ihnen die erste Option angezeigt, aber manchmal ist es hilfreich zu wissen, dass es eine zweite Option gibt.