2016-05-06 5 views
10

Ich habe ein Android Studio-Projekt mit zwei Bibliotheksmodulen: foo-module und bar-module. Jede implementiert eine Bibliothek, wobei foo-module eine Strategie-Schnittstelle definiert und bar-module abhängig von foo-module und eine solche Strategie implementiert. foo-module hat Instrumentierungstests (foo-module/src/androidTest/), um seinen Kerncode zu testen, unter Verwendung einer Stub-Strategie-Implementierung, und bar-module sollte seine eigenen Instrumentierungstests haben.Wie übernehmen wir Testklassen in Android-Bibliotheksmodulen?

Ich definierte eine Klasse in foo-module/src/androidTest/, die meisten der tatsächlichen Tests. Ich habe auch eine StubTests Klasse in foo-module/src/androidTest/, die AbstractTests erweitert und implementiert die notwendigen abstract Methoden, um den Testfall (Bereitstellung einer Implementierung der Strategie, etc.) zu vervollständigen. Das alles funktioniert großartig.

In bar-module/src/androidTest/, habe ich eine BarStrategyTests Klasse, entworfen StubTests, spiegeln aber die Strategie in bar-module umgesetzt bieten. kann jedoch nicht sehen, obwohl ich compile project(':foo-module') in meiner build.gradle Datei habe, und die Hauptklassen (Nicht-Test) in bar-module können gut mit den Hauptklassen (Nicht-Test) in foo-module funktionieren. IOW, während die project() Abhängigkeit behandelt normalen Code, behandelt es nicht androidTest/ Code. Ich bekomme "Fehler: Paket com.commonsware.foo.test existiert nicht".

Ich habe versucht, auch androidTestCompile project(':foo-module'), mit dem gleichen Ergebnis.

Wie lautet das Rezept für den Austausch von Instrumentierungstestcode zwischen Modulen?

Vorübergehend kann ich AbstractTests klonen, aber das ist keine große langfristige Lösung.

This SO question deckt ähnlichen Boden für gewöhnliches Java. Hat jemand die Optionen in the one answer ausprobiert und sie für Android Instrumententests arbeiten lassen? Die erste Option (den üblichen Testcode in einen anderen Modul als normalen Nicht-Testcode zu verschieben) erscheint plausibel, aber ich habe keine Ahnung, ob die anderen beiden gut mit dem com.android.library Plugin anstelle des java Plugins funktionieren.

+0

Haben Sie einen Weg gefunden, dies zu erreichen? Ich möchte meine Testklassen auch für die anderen Module zur Verfügung stellen, aber ich habe Schwierigkeiten, die Ressourcen zu teilen. – karate

+1

@karate: Ich verwende den in der angenommenen Antwort beschriebenen Ansatz. – CommonsWare

Antwort

8

Aufgrund der Tatsache, dass alle Testklassen (Einheit und Instrumentierung) nicht Teil eines Moduls einschließlich aar sind, sind sie nicht über die Abhängigkeit zu diesem Modul verfügbar. Ich habe mich auch diesem Problem gestellt und es gelöst, indem ich test-module erstellt habe und alle erforderlichen Klassen darin eingefügt habe (src/main/java). In diesem Fall können Sie AbstractTests in diesem Modul verschieben und dieses Modul als androidTestCompile Abhängigkeit verwenden.

+0

Ich kann definitiv sehen, dass ich etwas anderes machen muss, wenn ich von einem vorgefertigten AAR abhängig bin, wie zum Beispiel einem Repository-Artefakt. Ich hatte erwartet, dass 'compile project (': foo-module')' die passenden Quellsätze zusammenbringen würde - schließlich ist es nicht 'compile projectButJustTheMainSourcesetPlease (': foo-modul ')'. :-) Ich werde das für eine Weile offen lassen, um zu sehen, ob jemand anderes eine andere Option hat, aber ich werde nicht geschockt sein, wenn es dir am besten gefällt. Danke für die Hilfe! – CommonsWare

+1

Beachten Sie, dass dieser Ansatz mehrere zusätzliche Module erfordert. Grundsätzlich kann 'foo-module' keine eigenen Tests haben."AbstractTests" müssen nicht nur auf "foo-modul-test-common" verschoben werden, sondern alle bisherigen Tests in 'foo-modul' müssen in' foo-modul-test' überführt werden. Andernfalls erhalten Sie zirkuläre Abhängigkeiten: 'foo-module' hat' androidTestCompile' auf 'foo-modul-test-common', das' compile' auf 'foo-module' hat. 'foo-module' kann dadurch nicht von' foo-modul-test-common' abhängig sein. Was für ein Schmerz. – CommonsWare

+2

Nun, Sie müssen vermeiden, 'foo-Modul' hängt von' foo-modul-test-common' ab. Eine Option besteht darin, alle Tests von 'foo-modul' nach' foo-modul-test-common' zu verschieben, so dass dieses Modul nicht nur allgemeine Testklassen in 'src/main/java' enthält, sondern auch die Tests für' foo enthält -module in 'src/androidTest/java'. –

Verwandte Themen