Ich habe früher in MVP gearbeitet und teste meine Moderatoren normalerweise mit einem einfachen Junit (Nicht die Instrumentierung!), da Presenter nur die Geschäftslogik und keinerlei Verweise auf Android-Interna haben.
Nachdem ich nun zu Dagger 2 gewechselt habe, habe ich ein Problem damit, ein "TestModul" für meine App-Komponente einzurichten.
Nur um die Dinge klar zu machen, ich spreche über die Tests, die in app- & gt; src & gt; Test-Ordner nicht die app- & gt; src & gt; androidTest!
Also mache ich etwas falsch? Oder etwas fehlt? Kann jemand erklären oder Beispiele geben, wie man Dolch 2 in normalen Komponententests verwendet?
Ich bin mir nicht sicher, ob meine Lösung für Sie funktionieren wird, aber ich sehe keinen Grund, warum das nicht funktionieren sollte. Zuerst habe ich testInjectionComponent
erstellt %Vor%Dann meine Unit Tests Ich füge die Injektion in der Vorher-Methode hinzu. so:
%Vor%Dann notiere ich einfach mein eingesendetes Objekt.
BEARBEITEN:
Vergessen Sie nicht, testApt "com.google.dagger:dagger-compiler:$daggerVersion" in Ihrer App-Hauptdatei hinzuzufügen.
Sie brauchen keinen Dolch, um Ihren Moderator zu testen. Daggers Aufgabe ist es, die Abhängigkeiten Ihrer Klassen zu erfüllen (Dependency Injection).
Zum Beispiel haben Sie diesen Presenter:
%Vor% Dagger stellt Ihrem Moderator die Objekte database und apiService zur Verfügung, damit Ihr Moderator sie verwenden kann. Beim Ausführen der eigentlichen App (kein Test) handelt es sich um echte Objekte mit echter Funktionalität.
Wenn Sie den Moderator testen, möchten Sie nur den Präsentator testen, alles andere sollte gespottet werden.
Wenn Sie also den Moderator in Ihrem PresenterTest erstellen, erstellen Sie ihn mit gespotteten Versionen von database und apiService .
Sie können dann testen, wie Ihr Moderator mit diesen Objekten interagiert, indem Sie
drückena. das Verhalten der Objekte verspotten wie
%Vor%b. Überprüfen Sie, ob Ihr Präsentator das tut, was Sie mit diesen Objekten tun möchten, wie
%Vor%(Pseudocode)
Die übliche Art zu spotten wäre Mockito.
Sie können echte Module mit gefälschten Modulen auf zwei Arten austauschen: Führen Sie das Kompilieren mit Aromen aus, wie von google architecture samples oder zur Laufzeit, indem eine abstrakte Methode erstellt wird, die den echten Produktionscode und falsche Abhängigkeiten in den Testcode einbringt. Im zweiten Fall muss Ihr Test die Klasse, die Sie vortäuschen wollen, ableiten und die Komponente von scrach erstellen