如果我们只使用普通的 Dagger 2. 在 application
类中,我们将有一个包含 AppComponent
的属性。然后我们可以在 Espresso 测试期间交换它。
但是当我使用 dagger-android 2.15
设置我的项目时。如果采用过多的 Dagger 魔法,事情就会变得更加含蓄。代码更干净,但使测试有点困难。
这是应用程序
类:
class App : DaggerApplication() {
override fun applicationInjector(): AndroidInjector<out DaggerApplication> {
return DaggerAppComponent
.builder()
.create(this)
.build()
}
}
这是 HomeActivity
class HomeActivity : DaggerAppCompatActivity() {
@Inject
lateinit var userPreference: UserPreference
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_home)
if (!this.userPreference.memberRegistered) {
goToActivity(EntryActivity::class.java)
}
}
}
以这段代码为例。如何模拟注入(inject)的 userPreference.memberRegistered
这可能是下面的 HTTP 调用?
最佳答案
对于那些对此感兴趣的人,我得到了一个blog一步一步的详细信息:
基本上,这个想法是:
- 您仍然在@Module 中生成用于注入(inject)的实例
- 但是我们将创建新的@Component A 仅用于测试
- 这个@Component 将有一个方法来获取那个@Module
- 在测试期间,我们将应用程序使用的@Component 与我们的组件 A 交换
那么事情就简单了:
没有 DaggerMock
- 在@Module 中,不返回真实实例,而是返回 mockito mock。
使用 DaggerMock
- 声明要交换的类型并模拟它
- 然后您可以使用模拟。
- 无需更改@Module
它受到@AutonomousApps 的解决方案的启发,但不同之处在于现在您不需要为每个测试类编写@Component、@Module。
关于android - 编写 espresso 测试时如何在设置 dagger-android 2.15 后进行模拟?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49896424/