如Mockito 2 docs中所述,我们现在可以模拟最终类,所以我尝试在一个简单的项目中进行,但结果不合适。 这是我的项目结构
这是org.mockito.plugins.MockMaker文本文件
mock-maker-inline
以下是测试的演示活动
class LoginActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_login)
}
private fun onLoginPressed(email:String, password:String){
}
fun isEmailValid(email: String):Boolean{
return true
}
}
这是测试类
class LoginActivityTest{
@Test
fun checkLoginValidity(){
val lognActivity = Mockito.mock(LoginActivity::class.java)
assert(lognActivity.isEmailValid("yuo"))
}
}
测试应该已经过去,因为我总是回归真实,但这就是我得到的。
我还标记并取消标记资源目录作为测试资源root,但没有发生任何事情。
你能指出我,我错在哪里吗?
答案 0 :(得分:1)
使用Mockito模拟最终(Kotlin)课程工作正常,你的设置显然是正确的(如果嘲笑Activity
失败,你会收到错误)。你试图测试的方式有问题。
Mockito用于模拟要测试的类的依赖项,而不是要测试自己的类。
你正在做的是模仿你的LoginActivity
,然后断言它返回一些值。对于返回类似boolean
的{{1}}的方法,默认情况下模拟返回isEmailValid(...)
。
你没有测试嘲笑,没有任何意义。您想测试被测试类的“真实”实例。
如果您想测试false
,则只需使用Activity
创建一个,然后执行val classToTest = LoginActivity()
。
这可能(不确定)适用于这个非常简单的情况,但一般情况下你不会对assert
进行单元测试,因为有太多特定于Android的内容,比如给布局充气({ {1}})在单元测试中不起作用。
这就是为什么像MVP或MVVM这样的概念越来越受欢迎,以便从像Activity
这样的Android类中移除尽可能多的逻辑,然后使其可测试。
根据您的情况,为了帮助您入门,您可以编写一个setContentView
课程。然后在您的活动中使用以检查电子邮件Activity
和b。可以通过单元测试更好地测试。
答案 1 :(得分:1)
你嘲笑了你的Activity
课程,所以它的所有方法都会返回"默认"值(boolean
为false
)。你需要说Mockito
来调用真正的类方法。
`when`(lognActivity.isEmailValid(ArgumentMatchers.any() ?: ""))
.thenCallRealMethod()
顺便说一下,最好只将该解决方案用于抽象类,因为你不能用另一种方式创建它的实例。如果您的课程不是抽象的,只需创建它(对Activity
测试更好,以便使用specific tools)。