Bitte beachten Sie, dass dieser Artikel nicht beschreibt, wie Mockito selbst verwendet wird. Enthält viele Beschreibungen für Android.
Wenn Sie Mockito wie in Kotlin verwenden, erhalten Sie den folgenden Code.
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)
Der obige Code ist der Code, der die SharedPreferences von Android verspottet.
sharedPreferences.edit () gibt einen verspotteten Editor zurück, mit dem Sie commit () und putString () verwenden können.
Die mock () Methode, die das Mock-Objekt erstellt, ist in Ordnung, aber der Teil der when () -Methode, der das Verhalten des Mock-Objekts bestimmt, ist von Anführungszeichen umgeben, was sehr schwer zu erkennen ist.
Natürlich gibt es kein Problem, aber diesmal ist es eine Bibliothek, die den Code zu einem Teil dieses Modells macht, das eher Kotlin, ** mockito-kotlin ** ähnelt. Ich würde gerne Kotlin verwenden.
Fügen Sie auf jede Weise Bibliotheksreferenzen hinzu, z. B. Gradle oder Maven.
//testImplementation ist an die Umgebung angepasst
testImplementation "com.nhaarman:mockito-kotlin:1.5.0"
Anstatt die Klasse als Argument zu übergeben, wird sie von Generika angegeben.
val sharedPreferences = mock<SharedPreferences> {}
Die im zweiten und den nachfolgenden Argumenten übergebenen Optionen werden weiterhin in den Methodenargumenten beschrieben.
val editor = mock<SharedPreferences.Editor>(defaultAnswer = RETURNS_DEEP_STUBS) { }
Der gesamte Inhalt von withSettings () kann auch als Argument übergeben werden.
//Folgende Argumente können verwendet werden(1.5.0 vorhanden)
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
Verwenden Sie nicht "when", sondern beschreiben Sie es im Funktionsargument "{}", wenn Sie ein Modell erstellen. Verwenden Sie "on {method to mock ()}", um die Methode zum Verspotten des Verhaltens anzugeben, gefolgt von "doReturn", "doAnswer" und "doThrow". Der folgende Code entspricht dem am Anfang des Artikels eingeführten Mockito-Code.
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
}
//Unten ist der Code am Anfang des Artikels
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
Der kontinuierlich geschriebene Wert ist der Rückgabewert der zu verspottenden Methode. Wenn der Rückgabewert "void" oder "Unit" ist, gibt es kein Problem, wenn Sie "Unit" zurückgeben.
val stringMock = mock<String> {
on { toString() } doReturn "mocked"
}
stringMock.toString() // => "mocked"
doAnswer
Schreiben Sie eine Funktion, die ein verspottetes Objekt als Empfänger verwendet und den Typ zurückgibt, den die Methode zurückgeben soll. Es ist wie "lassen".
val stringMock = mock<String> {
on { toString() } doAnswer { "mocked" + it.hashCode() }
}
stringMock.toString() // => "mocked[Zahlen]"
doThrow
Wirf die Ausnahme, die du nacheinander geschrieben hast.
val stringMock = mock<String> {
on { toString() } doThrow RuntimeException()
}
stringMock.toString() // => RuntimeException
Sie können "any ()" und "argThat ()" verwenden, um das Argument der zu verspottenden Methode anzugeben, daher denke ich, dass die Grundlagen kein Problem darstellen werden. Bei anderen Schreibmethoden ist es leicht zu verstehen, wenn Sie sich das Github-Wiki und den Testcode ansehen. Wenn Sie also nicht wissen, wie man es schreibt, sollten Sie es sich ansehen.
Wiki: https://github.com/nhaarman/mockito-kotlin/wiki/Mocking-and-verifying Testcode: https://github.com/nhaarman/mockito-kotlin/tree/2.x/tests/src/test/kotlin/test
Recommended Posts