Veuillez noter que cet article ne décrit pas comment utiliser Mockito lui-même. Contient de nombreuses descriptions pour Android.
Si vous utilisez Mockito tel qu'il est dans Kotlin, vous obtiendrez le code suivant.
val sharedPreferences = mock(SharedPreferences::class.java)
val editor = mock(SharedPreferences.Editor::class.java, RETURNS_DEEP_STUBS)
`when`(sharedPreferences.edit()).thenReturn(editor)
`when`(editor.commit()).thenReturn(true)
`when`(editor.putString(anyString(), anyString())).thenReturn(editor)
Le code ci-dessus est le code qui se moque des SharedPreferences d'Android.
sharedPreferences.edit () renvoie un éditeur plus moqueur, vous permettant d'utiliser commit () et putString ().
La méthode mock () qui crée l'objet fictif est correcte, mais la partie de la méthode when () qui détermine le comportement de l'objet fictif est entourée de guillemets, ce qui est très difficile à voir.
Cela se produit parce que le mot «quand» est réservé dans Kotlin et doit être échappé par des guillemets.
Bien sûr, il n'y a pas de problème en l'état, mais cette fois, c'est une bibliothèque qui fait que le code fait partie de ce simulacre plus comme Kotlin, [** mockito-kotlin **](https://github.com/nhaarman/mockito- Je voudrais utiliser kotlin).
Ajoutez des références de bibliothèque de chaque manière, comme Gradle ou Maven.
//testLa mise en œuvre est adaptée à l'environnement
testImplementation "com.nhaarman:mockito-kotlin:1.5.0"
Au lieu de passer la classe en argument, elle sera spécifiée par des génériques.
val sharedPreferences = mock<SharedPreferences> {}
Les options passées dans le deuxième argument et les suivants continueront à être décrites dans les arguments de la méthode.
val editor = mock<SharedPreferences.Editor>(defaultAnswer = RETURNS_DEEP_STUBS) { }
Tout le contenu de withSettings () peut également être passé comme arguments.
//Les arguments qui peuvent être utilisés sont les suivants(1.5.0 présent)
extraInterfaces: Array<KClass<out Any>>? = null
name: String? = null
spiedInstance: Any? = null
defaultAnswer: Answer<Any>? = null
serializable: Boolean = false
serializableMode: SerializableMode? = null
verboseLogging: Boolean = false
invocationListeners: Array<InvocationListener>? = null
stubOnly: Boolean = false
useConstructor: Boolean = false
outerInstance: Any? = null
stubbing: KStubbing<T>.(T) -> Unit
N'utilisez pas when, mais décrivez-le dans l'argument de fonction {} lors de la création d'une maquette.
ʻOn {Mocking method ()} Spécifiez la méthode pour simuler l'opération avec, suivie de doReturn, doAnswer, doThrow`.
Le code ci-dessous est équivalent au code Mockito introduit au début de l'article.
val editor = mock<SharedPreferences.Editor>(defaultAnswer = RETURNS_DEEP_STUBS) {
on { commit() } doReturn true
on { putString(anyString(), anyString()) } doReturn it
}
val sharedPreferences = mock<SharedPreferences> {
on { edit() } doReturn editor
}
//Ci-dessous le code au début de l'article
val sharedPreferences = mock(SharedPreferences::class.java)
val editor = mock(SharedPreferences.Editor::class.java, RETURNS_DEEP_STUBS)
`when`(sharedPreferences.edit()).thenReturn(editor)
`when`(editor.commit()).thenReturn(true)
`when`(editor.putString(anyString(), anyString())).thenReturn(editor)
doReturn
La valeur écrite en continu sera la valeur de retour de la méthode à simuler.
Si la valeur de retour est void ou ʻUnit, il est possible de retourner ʻUnit.
val stringMock = mock<String> {
on { toString() } doReturn "mocked"
}
stringMock.toString() // => "mocked"
doAnswer
Ecrivez une fonction qui prend un objet simulé comme récepteur et renvoie le type que la méthode est censée renvoyer. C'est comme «let».
val stringMock = mock<String> {
on { toString() } doAnswer { "mocked" + it.hashCode() }
}
stringMock.toString() // => "mocked[Nombres]"
doThrow
Jetez l'exception que vous avez écrite successivement.
val stringMock = mock<String> {
on { toString() } doThrow RuntimeException()
}
stringMock.toString() // => RuntimeException
Vous pouvez utiliser ʻany () ʻet ʻargThat () `dans la partie de la spécification de l'argument de la méthode à moquer, donc je pense que les bases ne seront pas un problème. Pour les autres méthodes d'écriture, il est facile à comprendre en regardant le Wiki Github et le code de test, donc si vous ne savez pas comment l'écrire, vous devriez le regarder.
Wiki: https://github.com/nhaarman/mockito-kotlin/wiki/Mocking-and-verifying Code de test: https://github.com/nhaarman/mockito-kotlin/tree/2.x/tests/src/test/kotlin/test
Recommended Posts