2016-05-06 7 views
10

Ho un progetto Android Studio con due moduli di libreria: foo-module e bar-module. Ciascuno implementa una libreria, con foo-module che definisce un'interfaccia di strategia e bar-module a seconda di foo-module e implementando tale strategia. foo-module ha test di strumentazione (foo-module/src/androidTest/) per testare il proprio codice core, utilizzando un'implementazione della strategia di stub, e bar-module dovrebbe avere i propri test di strumentazione.In che modo ereditiamo le classi di test nei moduli della libreria Android?

Ho definito una classe AbstractTests in foo-module/src/androidTest/ che esegue la maggior parte dei test effettivi. Ho anche una classe StubTests in foo-module/src/androidTest/ che si estende AbstractTests e implementa i metodi necessari abstract per completare il test case (fornendo un'implementazione della strategia, ecc.). Tutto funziona alla grande.

In bar-module/src/androidTest/, ho creato una classe BarStrategyTests, progettata per il mirroring StubTests, ma fornire la strategia implementata in bar-module. Tuttavia, BarStrategyTests non può vedere AbstractTests, anche se ho compile project(':foo-module') nel mio file build.gradle e le classi principali (non test) in bar-module possono funzionare correttamente con le classi principali (non test) in foo-module. IOW, mentre la dipendenza project() gestisce il codice normale, non gestisce il codice androidTest/. Ottengo "errore: il pacchetto com.commonsware.foo.test non esiste".

Ho provato anche ad aggiungere androidTestCompile project(':foo-module'), con lo stesso risultato.

Qual è la ricetta per condividere il codice di test della strumentazione tra i moduli?

Temporaneamente, posso clonare AbstractTests, ma questa non è una soluzione a lungo termine.

This SO question copre un terreno simile per Java ordinario. Qualcuno ha provato le opzioni in the one answer e le ha fatte funzionare per i test di strumentazione Android? La prima opzione (spostare il codice di test comune in un altro modulo come normale codice non di test) sembra plausibile, ma non ho idea se gli altri due funzioneranno bene con il plugin com.android.library invece del plug-in java.

+0

hai trovato un modo per raggiungere questo? Voglio rendere le mie classi di test disponibili anche per gli altri moduli, ma ho difficoltà a condividere le risorse. – karate

+1

@karate: sto utilizzando l'approccio delineato nella risposta accettata. – CommonsWare

risposta

8

A causa del fatto che tutte le classi di test (unità e strumentazione) non fanno parte di alcun modulo, incluso aar, non sono disponibili tramite dipendenza da quel modulo. Ho affrontato anche questo problema e l'ho risolto creando test-module e inserendo tutte le classi richieste (src/main/java). Quindi, nel tuo caso puoi spostare AbstractTests in questo modulo e usare questo modulo come dipendenza androidTestCompile.

+0

Posso sicuramente vedere che devo fare qualcosa di diverso se dipendessi da un AAR preconfezionato, come un artefatto del repository. Mi aspettavo che 'compile project (': foo-module')' corrispondesse agli sourcesets appropriati - dopotutto non è 'compile projectButJustTheMainSourcesetPlease (': foo-module')'. :-) Ho intenzione di lasciarlo aperto per un po 'per vedere se qualcun altro ha un'altra opzione, ma non sarò scioccato se la tua sarà la scelta migliore. Grazie per l'aiuto! – CommonsWare

+1

Si noti che questo approccio sembra richiedere più moduli aggiuntivi. Fondamentalmente, 'foo-module' non può avere alcun test a sé stante.Non solo 'AbstractTests' deve essere spostato in' foo-module-test-common', ma qualsiasi test precedentemente in 'foo-module' deve essere spostato in' foo-module-test'. Altrimenti, si ottengono delle dipendenze circolari: 'foo-module' ha 'androidTestCompile' su' foo-module-test-common', che ha 'compile' su' foo-module'. 'foo-module' non può avere una dipendenza da' foo-module-test-common' come risultato. Che dolore. – CommonsWare

+2

Bene, devi evitare che 'foo-module' dipenda da' foo-module-test-common'. Un'opzione è di spostare tutti i test da 'foo-module' a' foo-module-test-common', quindi questo modulo non contiene solo classi di test comuni in 'src/main/java' ma contiene anche i test per' foo -module' in 'src/androidTest/java'. –

Problemi correlati