Last active
March 11, 2020 20:49
-
-
Save vaughandroid/2ac4aeb28d3e6b008fa4 to your computer and use it in GitHub Desktop.
Not quite the easiest way to override Dagger 2 modules for unit tests...
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@Component(modules=MyModule.class) | |
@ApplicationScope | |
public interface MyComponent { | |
void inject(MyApplication application); | |
} | |
@Module | |
public class MyModule { | |
@Provides @ApplicationScope | |
public String provideString() { | |
return "real string"; | |
} | |
} | |
public class MyApplication extends Application { | |
@Inject public String injectedString; | |
private MyComponent component; | |
public void setComponent(MyComponent component) { | |
this.component = component; | |
component.inject(this); | |
Log.d("Injected: " + injectedString); | |
} | |
@Override | |
public void onCreate() { | |
super.onCreate(); | |
if (component == null) { | |
setComponent(DaggerMyComponent.create()); | |
} | |
} | |
} | |
public class MyActivityTest { | |
MyApplication app; | |
@Before | |
public void setUp() { | |
app = (MyApplication) getInstrumentation().getTargetContext().getApplicationContext(); | |
// This is the sneaky bit. Create a partial mock of the Module you want to override, | |
// then just mock the provider methods you want to override. | |
MyModule module = Mockito.spy(new MyModule()); | |
Mockito.doReturn("mocked string").when(module).provideString(); | |
MyComponent component = DaggerMyComponent.builder() | |
.myModule(module) | |
.build(); | |
app.setComponent(component); | |
} | |
@Test | |
public void mock_injected_successfully() { | |
assertEquals("mocked string", app.injectedString); | |
} | |
} |
@mheras You've got to get a different Component instance in there somehow. I've seen options using build flavors which don't involve modifying the production code, but I'm happy to be pragmatic about it. My personal feeling is "testing trumps encapsulation".
I've posted a new gist here using @tbroyer's idea: https://gist.github.com/vaughandroid/00287633102af6a66dc8
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
... and you still need to call
setComponent
. You are making that methodpublic
in your production code just for testing purposes... That's bad from a design point of view.