2015-03-25 13 views
5

Uso Dagger2 nella mia app Android. Fondamentalmente inietto un HttpClient (interfaccia) in MainActivity.Modulo test di iniezione con dagger2

@Module 
public class MainActivityModule{ 

    @Provides public HttpClient providesHttpComponent(){ 
     return new RealHttpClient(); 
    } 
} 

@Component(modules = MainActivityModule.class) 
public interface MainActivityComponent { 
    public MainActivity injectActivity(MainActivity); 
} 



public class MainActivity extends Activity { 

    public void onCreate(Bundle saved){ 
     super.onCreate(); 

     injectDependencies(); 
    } 


    protected void injectDependencies(){ 

     Dagger_MainActivityComponent 
     .builder() 
     .mainActivityComponent(new MainActivityModule()) 
     .build() 
     .injectActivity(this); 
    } 

} 

Fin qui tutto bene, funziona come previsto. Ora voglio scrivere alcuni test unitari (non test strumentazione Android) per MainActivity dove voglio usare TestMainActivityModule invece di MainActivityModule.

@Module (overrides = true) 
public class TestMainActivtiyModule extends MainActivityModule { 

    @Provides public HttpClient(){ 
     return new MockHttpClient(); 
    } 

} 

La mia domanda è: come faccio a forzare MainActivity da usare al posto di TestMainActivitiyModuleMainActivityModule? C'è una buona soluzione per questo?

Il mio approccio attuale è quello di utilizzare l'ereditarietà e per ignorare getModule(), qualcosa di simile

public class TestMainActivity extend MainActivity { 

    @Override 
    protected void injectDependencies(){ 

     Dagger_MainActivityComponent 
     .builder() 
     .mainActivityComponent(new TestMainActivtiyModule()) 
     .build() 
     .injectActivity(this); 
    } 
} 

ed eseguire unit test contro TestMainActivity invece di MainActivity.

Credo che funziona, ma uno dei problemi che sto affrontando con questo approccio è che non posso iniziare TestMainActivity con una Intent perché non posso specificare in AndroidManifest.xml

Qualcuno sa una migliore approccio per il test unitario con dagger2 su Android?

+1

Come commento iniziale, l'override del modulo non è una cosa in Pugnale 2.Il metodo è lì per non interrompere le compilazioni mentre le persone migrano, ma è deprecato e non ha alcun effetto su un progetto di Dagger 2. –

risposta

0

L'approccio che ho iniziato a utilizzare ha comportato il mantenimento di due moduli (uno per l'app, uno per il test) in varianti di build parallele (es .: app e integration). Ancora non sono sicuro di quanto bene questa soluzione sia scalabile in modo YMMV. Sarei molto felice di vedere una soluzione migliore!

Questo è anche un grande letto: http://engineering.circle.com/instrumentation-testing-with-dagger-mockito-and-espresso/

+2

Preferisco avere due moduli separati, quindi il post del blog di circle.com non è quello che voglio (dal momento che non voglio avere dipendenze di derisione nella mia app di rilascio). L'approccio delle varianti di costruzione suona meglio, ma non è ancora perfetto ... – sockeqwe

0

io consiglio veramente di controllare questo boilerplate in quanto è completamente basata su DI utilizzando Dagger2. Mostra anche come puoi sostituire le tue dipendenze nell'ambiente di test in modo molto pulito.

Le dipendenze attualmente gestiti dal piastra della caldaia sono i seguenti: dipendenza

  • database: incapsula tutte le operazioni del database.
  • Dipendenza delle preferenze condivise: si occupa delle preferenze condivise.
  • Dipendenza dei file locali: che riguarda il salvataggio dei file.
  • Analytics dipendenza: copre tutte le operazioni di segnalazione eventi Analytics back-end (GA, Segmento, FB, Flurry ..)
  • registrazione dipendenza: incapsula tutte le operazioni relative alla registrazione alla console
  • Api dipendenza: incapsula tutte le operazioni legate all'API

La potenza dell'iniezione delle dipendenze è molto utile soprattutto per i test poiché è possibile passare facilmente le dipendenze nell'ambiente di test a dipendenze fittizie.

Problemi correlati