2015-03-25 11 views
5

Używam Dagger2 w mojej aplikacji na Androida. Zasadniczo wstrzykuję HttpClient (interfejs) w MainActivity.Wstrzykiwanie modułu testowego za pomocą sztyletu2

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

} 

Jak dotąd tak dobrze, że działa tak, jak się spodziewano. Teraz chcę napisać kilka testów jednostkowych (nie androidowych testów instrumentacji) dla MainActivity, gdzie chcę użyć TestMainActivityModule zamiast MainActivityModule.

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

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

} 

Moje pytanie brzmi: Jak mogę zmusić MainActivity używać TestMainActivitiyModule zamiast MainActivityModule? Czy istnieje dobre rozwiązanie?

Moje obecne podejście jest użycie dziedziczenia i zastąpić getModule(), coś jak ten

public class TestMainActivity extend MainActivity { 

    @Override 
    protected void injectDependencies(){ 

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

i uruchamianie testów jednostkowych przed TestMainActivity zamiast MainActivity.

Myślę, że to działa, ale jeden z problemów stojących jestem z tego podejścia jest to, że nie można uruchomić TestMainActivity z Intent bo nie można określić go w AndroidManifest.xml

Czy ktoś wie lepiej podejście do testowania jednostkowego za pomocą sztyletu 2 na Androida?

+1

Jako wstępny komentarz, nadpisanie modułów nie jest rzeczą w sztyletie 2.Metoda polega na tym, aby nie niszczyć kompilacji podczas migracji, ale jest przestarzała i nie ma wpływu na projekt sztyletu 2. –

Odpowiedz

0

Podejście, którego używałem, polegało na utrzymaniu dwóch modułów (jeden dla aplikacji, jeden do testowania) w równoległych wariantach kompilacji (np. app i integration). Nadal nie wiesz, jak dobrze to rozwiązanie skaluje, więc YMMV. Byłbym bardzo szczęśliwy, gdyby zobaczyłem lepsze rozwiązanie!

Jest również doskonałym odczytu: http://engineering.circle.com/instrumentation-testing-with-dagger-mockito-and-espresso/

+2

Wolę mieć dwa osobne moduły, więc blog blogu circle.com nie jest tym, czego chcę (ponieważ nie chcę mieć kpiących zależności w mojej aplikacji do wydawania). Podejście do wariantów budowy brzmi lepiej, ale wciąż nie jest idealne ... – sockeqwe

0

Chciałbym naprawdę proponuję, aby sprawdzić ten boilerplate ponieważ jest w pełni oparta na DI użyciu Dagger2. Pokazuje również, w jaki sposób można zastąpić zależności w środowisku testowym w bardzo zgrabny sposób.

Zależności aktualnie obsługiwane przez płytę kotła są następujące: zależnościami

  • Baza: obudowuje wszystkie operacje bazy danych.
  • Zależność zależna od preferencji: dotyczy preferencji współdzielonych.
  • Zależność od plików lokalnych: która dotyczy zapisywania plików.
  • zależność Analytics: obejmuje wszystkie działania imprez dla backend Analytics (GA, Segment, FB, Flurry ..)
  • zależność Logging raportowania: obudowuje wszystkie operacje związane zalogowaniu do konsoli
  • zależności
  • API: obejmuje wszystkie operacje związane z interfejsem API:

Moc zastrzyku zależności jest bardzo przydatna, szczególnie w przypadku testów, ponieważ można łatwo zmienić zależności w środowisku testowym na zależne od nich zależności.

Powiązane problemy