Módulo de prueba de inyección con dagger2

Yo uso Dagger2 en mi aplicación para Android. Básicamente me inyecto un HttpClient (interfaz) en MainActivity .

 @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); } }

Hasta ahora tan bueno, que funciona como se esperaba. Ahora quiero escribir algunas pruebas unitarias (no pruebas de instrumentación de android) para MainActivity donde quiero usar TestMainActivityModule lugar de MainActivityModule .

 @Module (overrides = true ) public class TestMainActivtiyModule extends MainActivityModule { @Provides public HttpClient(){ return new MockHttpClient(); } }

Mi pregunta es: ¿Cómo puedo forzar a MainActivity a usar TestMainActivitiyModule lugar de MainActivityModule ? ¿Hay una buena solución para eso?

Mi enfoque actual es utilizar la herencia y anular getModule() , algo como esto

 public class TestMainActivity extend MainActivity { @Override protected void injectDependencies(){ Dagger_MainActivityComponent .builder() .mainActivityComponent( new TestMainActivtiyModule()) .build() .injectActivity(this); } }

Y para ejecutar la prueba de unidad en TestMainActivity lugar de MainActivity .

Supongo que funciona, pero uno de los problemas que estoy enfrentando con este enfoque es que no puedo iniciar TestMainActivity con un Intent porque no puedo especificarlo en AndroidManifest.xml

¿Alguien sabe un mejor enfoque para las pruebas de unidad con dagger2 en Android?

El enfoque que he comenzado a utilizar ha implicado el mantenimiento de dos módulos (uno para la aplicación, uno para la prueba) en las variantes de construcción paralelas (por ejemplo: la app y la integration ). Todavía no estoy seguro de lo bien que la solución escalas YMMV. Estaría muy feliz de ver una solución mejor!

Esto también es una gran lectura: http://engineering.circle.com/instrumentation-testing-with-dagger-mockito-and-espresso/

Realmente le sugiero que revise este boilerplate ya que está totalmente basado en DI usando Dagger2. También muestra cómo puede reemplazar sus dependencias en el entorno de prueba de una manera muy ordenada.

Las dependencias actualmente manejadas por la placa de la caldera son las siguientes:

Dependencia de la base de datos: encapsula todas las operaciones de la base de datos.
Dependencia de preferencias compartidas: trata de las preferencias compartidas.
Dependencia de archivos locales: que se ocupa del ahorro en archivos.
Dependencia de Analytics: cubre toda la operación de reportar eventos a su backend de análisis (GA, Segmento, FB, Flurry ..)
Dependencia de registro: encapsula todas las operaciones relacionadas con el registro en la consola
Dependencia Api: encapsula todas las operaciones relacionadas con API

La energía de la inyección de la dependencia viene realmente práctico especialmente para la prueba puesto que usted puede cambiar fácilmente sus dependencias en el ambiente de la prueba a dependencias ficticias.