Debugging Mockito: Menyelesaikan kesalahan 'Wanted but not invoked' dalam tes plugin Gradle
Diterbitkan 17 November 2024
- Pendahuluan
- Konteks : Plugin Gradle Bakery
- Masalah #1: Memeriksa mock yang salah
- Masalah #2 : UnfinishedStubbingException berantai
- Masalah #3: File konfigurasi tidak ada
- Masalah #4 : afterEvaluate dan NullPointerException
- Solusi lengkap
- Pelajaran yang dipelajari
- Arsitektur pengujian akhir
- Kesimpulan
- Sumber daya
Pendahuluan
Selama pengembangan plugin GradleToko rotiUntuk blog JBake saya, saya telah menemui masalah yang tampak sederhana: sebuah tes unit yang gagal dengan kesalahan`Wanted but not invoked`. Apa yang terlihat sebagai bug trivial ternyata menjadi contoh kasus yang sempurna untuk memahami kehalusan mocking dengan Mockito dan Kotlin.
Dalam artikel ini, saya mengajak Anda melakukan perjalanan debugging metodis, di mana setiap solusi mengungkapkan masalah baru, hingga penyelesaian akhir.
Konteks : Plugin Gradle Bakery
Plugin Bakery adalah sebuah wrapper di sekitar JBake yang memudahkan publikasi situs statis. Berikut adalah struktur yang disederhanakannya :
class BakeryPlugin : Plugin<Project> {
override fun apply(project: Project) {
val extension = project.extensions.create(
"bakery",
BakeryExtension::class.java
)
project.afterEvaluate {
if (!project.layout.projectDirectory.asFile
.resolve(extension.configPath.get()).exists()) {
println("config file does not exists")
} else {
// C'EST ICI QUE ÇA SE PASSE
project.plugins.apply(JBakePlugin::class.java)
val site = FileSystemManager.from(project, extension.configPath.get())
// Configuration de JBake...
}
}
}
}
Uji yang gagal adalah sederhana:
@Test
fun `plugin applies jbake gradle plugin`() {
val project = createMockProject()
val plugin = BakeryPlugin()
plugin.apply(project)
verify(project.plugins).apply(JBakePlugin::class.java)
}
Kesalahan:
Wanted but not invoked:
pluginContainer.apply(class org.jbake.gradle.JBakePlugin);
Actually, there were zero interactions with this mock.
Masalah #1: Memeriksa mock yang salah
Diagnosa
@startuml actor Test participant "project.plugins" as PP participant "mockPluginContainer" as MPC participant "BakeryPlugin" as BP Test -> Test: createMockProject() activate Test Test -> MPC: create mock Test -> PP: doReturn mockPluginContainer Test --> Test: return project deactivate Test Test -> BP: apply(project) activate BP BP -> PP: project.plugins PP --> BP: returns mockPluginContainer BP -> MPC: apply(JBakePlugin::class.java) deactivate BP Test -> PP: verify(project.plugins).apply(...) note right ❌ ÉCHEC ! Mockito vérifie "project.plugins" mais l'interaction a eu lieu sur "mockPluginContainer" end note @enduml
Masalah: Mockito tidak dapat melacak interaksi pada`project.plugins`karena itu hanyalah getter yang mengembalikan mock sebenarnya`mockPluginContainer`. Pemeriksaan harus dilakukan langsung pada instance mock.
Solusi
Edit`createMockProject()`untuk mengembalikan kedua objek:
private fun createMockProject(): Pair<Project, PluginContainer> {
val mockPluginContainer = mock<PluginContainer>()
val mockProject = mock<Project> {
on { plugins } doReturn mockPluginContainer
}
return Pair(mockProject, mockPluginContainer)
}
Dan sesuaikan tes :
@Test
fun `plugin applies jbake gradle plugin`() {
val (project, mockPluginContainer) = createMockProject()
val plugin = BakeryPlugin()
plugin.apply(project)
// ✅ Vérification directe sur le bon mock
verify(mockPluginContainer).apply(JBakePlugin::class.java)
}
Masalah #2 : UnfinishedStubbingException berantai
Diagnosa
Setelah perbaikan pertama diterapkan, sebuah kesalahan baru muncul:
UnfinishedStubbingException:
Unfinished stubbing detected here
Hints:
3. you are stubbing the behaviour of another mock inside
before 'thenReturn' instruction is completed
Kode bermasalah menggunakan sintaksis DSL Mockito-Kotlin :
val mockProject = mock<Project> {
on { extensions } doReturn mockExtensionContainer
on { plugins } doReturn mockPluginContainer
on { logger } doReturn mock() // ❌ PROBLÈME ICI !
}
@startuml
participant "Mockito" as M
participant "Pembangun Mock" as MB
participant "Mock inline" as IM
M -> MB: mock<Project> { ... }
activate MB
MB -> MB: on { logger } doReturn
MB -> IM: mock()
activate IM
note right
❌ Création d'un nouveau mock
PENDANT le stubbing en cours !
Mockito perd le contexte
du stubbing parent
end note
IM --> MB: nouveau mock
deactivate IM
MB -x M: UnfinishedStubbingException
deactivate MB
@enduml
Solusi
Membuatsemuamock di luar blok stubbing apa pun, lalu konfigurasikan dengan`whenever()` :
private fun createMockProject(): Pair<Project, PluginContainer> {
// 1️⃣ Créer TOUS les mocks d'abord
val mockPluginContainer = mock<PluginContainer>()
val mockExtensionContainer = mock<ExtensionContainer>()
val mockLogger = mock<org.gradle.api.logging.Logger>()
val mockProject = mock<Project>()
// 2️⃣ Configurer les mocks séparément avec whenever()
whenever(mockProject.plugins).thenReturn(mockPluginContainer)
whenever(mockProject.extensions).thenReturn(mockExtensionContainer)
whenever(mockProject.logger).thenReturn(mockLogger)
return Pair(mockProject, mockPluginContainer)
}
|
Aturan emas: Jangan pernah menelepon`mock()`di dalam blok konfigurasi mock. Selalu buat mock terlebih dahulu, lalu konfigurasikan. |
Masalah #3: File konfigurasi tidak ada
Diagnosa
Meskipun dengan mocks yang benar, test terus gagal karena plugin tidak dapat menemukan file konfigurasi :
// Dans BakeryPlugin.kt
if (!project.layout.projectDirectory.asFile
.resolve(extension.configPath.get()).exists()) {
println("config file does not exists")
return@afterEvaluate // ❌ Sort avant d'appliquer JBake !
}
@startuml
participant "BakeryPlugin" as BP
participant "Tata Letak Proyek" as PL
participant "Ekstensi" as EXT
participant "FileSystem" as FS
BP -> PL: layout.projectDirectory.asFile
PL --> BP: /some/mock/path
BP -> EXT: extension.configPath.get()
EXT --> BP: "../../site.yml"
BP -> BP: resolve("../../site.yml")
BP -> FS: exists() ?
FS --> BP: false ❌
BP -> BP: return (skip JBake)
note right
Le plugin ne trouve pas
le fichier et sort
avant d'appliquer JBake
end note
@enduml
solusi
Konfigurasikan mocks agar resolusi jalur berfungsi:
private fun createMockProject(): Pair<Project, PluginContainer> {
// ... autres mocks ...
val configFile = File("../../site.yml").canonicalFile
val projectDir = configFile.parentFile
// Configuration cohérente des chemins
whenever(mockConfigPathProperty.get()).thenReturn("site.yml")
whenever(mockProjectDirectory.asFile).thenReturn(projectDir)
// Maintenant : projectDir.resolve("site.yml") existe ! ✅
}
@startuml
!define SUCCESS #90EE90
!define PROBLEM #FFB6C1
rectangle "Konfigurasi Mock" {
card "projectDirectory.asFile" SUCCESS
card "returns: /real/path/to/project" SUCCESS
card "configPath.get()" SUCCESS
card "mengembalikan: site.yml" SUCCESS
card "resolve()" SUCCESS
card "/real/path/to/project/site.yml" SUCCESS
card "ada()" SUCCESS
card "benar ✅" SUCCESS
}
@enduml
Masalah #4 : afterEvaluate dan NullPointerException
Diagnosa
Plugin ini menerapkan JBake dalam sebuah blok`afterEvaluate`, dan mengakses`buildDirectory.dir()`:
project.afterEvaluate {
// ...
project.tasks.withType(JBakeTask::class.java)
.getByName("bake").apply {
output = project.layout.buildDirectory
.dir(site.bake.destDirPath) // ❌ NPE ici !
.get()
.asFile
}
}
Mock dari`buildDirectory.dir()kembali`null.
solusi
mengejek`afterEvaluate`agar dieksekusi segera, dan mengkonfigurasi sepenuhnya`buildDirectory`:
private fun createMockProject(): Pair<Project, PluginContainer> {
// ... autres mocks ...
val mockBuildDirectory = mock<DirectoryProperty>()
val buildDir = File(projectDir, "build")
// Mocker dir() pour retourner un Provider valide
whenever(mockBuildDirectory.dir(any<String>())).doAnswer { invocation ->
val path = invocation.arguments[0] as String
val mockDirProvider = mock<Provider<Directory>>()
val mockDir = mock<Directory>()
whenever(mockDir.asFile).thenReturn(File(buildDir, path))
whenever(mockDirProvider.get()).thenReturn(mockDir)
mockDirProvider
}
// Mocker afterEvaluate pour exécution immédiate
whenever(mockProject.afterEvaluate(any<Action<Project>>())).doAnswer { invocation ->
val action = invocation.arguments[0] as Action<Project>
action.execute(mockProject) // ✅ Exécution synchrone
null
}
return Pair(mockProject, mockPluginContainer)
}
@startuml
participant "uji" as T
participant "BakeryPlugin" as BP
participant "proyek tiruan" as MP
participant "afterEvaluate Action" as AE
T -> BP: apply(project)
activate BP
BP -> MP: afterEvaluate { ... }
activate MP
note right
Mock configuré pour
exécuter immédiatement
end note
MP -> AE: execute(project)
activate AE
AE -> MP: layout.buildDirectory.dir("memanggang")
MP --> AE: Provider<Directory> ✅
AE -> MP: plugins.apply(JBakePlugin)
deactivate AE
MP --> BP:
deactivate MP
BP --> T:
deactivate BP
T -> T: verify(mockPluginContainer).apply(...)
note right: ✅ SUCCÈS !
@enduml
Solusi lengkap
Ini fungsi`createMockProject()`akhir, yang memecahkan semua masalah :
private fun createMockProject(): Pair<Project, PluginContainer> {
// 1️⃣ CRÉER tous les mocks (pas de nested mocks !)
val mockPluginContainer = mock<PluginContainer>()
val mockExtensionContainer = mock<ExtensionContainer>()
val mockLogger = mock<org.gradle.api.logging.Logger>()
val mockTaskContainer = mock<TaskContainer>()
val mockConfigPathProperty = mock<Property<String>>()
val mockBakeryExtension = mock<BakeryExtension>()
val mockProjectDirectory = mock<Directory>()
val mockBuildDirectory = mock<DirectoryProperty>()
val mockProjectLayout = mock<ProjectLayout>()
val mockProject = mock<Project>()
// 2️⃣ CONFIGURER la résolution des chemins
val configFile = File("../../site.yml").canonicalFile
val projectDir = configFile.parentFile
val buildDir = File(projectDir, "build")
whenever(mockConfigPathProperty.get()).thenReturn("site.yml")
whenever(mockConfigPathProperty.isPresent).thenReturn(true)
whenever(mockBakeryExtension.configPath).thenReturn(mockConfigPathProperty)
whenever(mockProjectDirectory.asFile).thenReturn(projectDir)
// 3️⃣ CONFIGURER buildDirectory avec dir()
whenever(mockBuildDirectory.dir(any<String>())).doAnswer { invocation ->
val path = invocation.arguments[0] as String
val mockDirProvider = mock<Provider<Directory>>()
val mockDir = mock<Directory>()
whenever(mockDir.asFile).thenReturn(File(buildDir, path))
whenever(mockDirProvider.get()).thenReturn(mockDir)
mockDirProvider
}
// 4️⃣ ASSEMBLER le projet
whenever(mockProjectLayout.projectDirectory).thenReturn(mockProjectDirectory)
whenever(mockProjectLayout.buildDirectory).thenReturn(mockBuildDirectory)
whenever(mockExtensionContainer.create("bakery", BakeryExtension::class.java))
.thenReturn(mockBakeryExtension)
whenever(mockExtensionContainer.getByType(BakeryExtension::class.java))
.thenReturn(mockBakeryExtension)
whenever(mockProject.extensions).thenReturn(mockExtensionContainer)
whenever(mockProject.plugins).thenReturn(mockPluginContainer)
whenever(mockProject.tasks).thenReturn(mockTaskContainer)
whenever(mockProject.layout).thenReturn(mockProjectLayout)
whenever(mockProject.logger).thenReturn(mockLogger)
whenever(mockProject.projectDir).thenReturn(projectDir)
// 5️⃣ CONFIGURER afterEvaluate pour exécution immédiate
whenever(mockProject.afterEvaluate(any<Action<Project>>())).doAnswer { invocation ->
val action = invocation.arguments[0] as Action<Project>
action.execute(mockProject)
null
}
return Pair(mockProject, mockPluginContainer)
}
Dan uji akhir yang lolos:
@Test
fun `plugin applies jbake gradle plugin`() {
val (project, mockPluginContainer) = createMockProject()
val plugin = BakeryPlugin()
plugin.apply(project)
verify(mockPluginContainer).apply(JBakePlugin::class.java) // ✅ SUCCÈS !
}
Pelajaran yang dipelajari
@startmindmap * Mocking avec Mockito ** ✅ Bonnes pratiques *** Créer tous les mocks d'abord *** Configurer avec whenever() séparément *** Vérifier le mock exact, pas un proxy *** Tester la résolution des chemins ** ❌ Pièges à éviter *** mock() dans un bloc de configuration *** Vérifier project.x au lieu de mockX *** Ignorer les blocs afterEvaluate *** Retourner null pour les Providers @endmindmap
Memeriksa mock yang benar
// ❌ FAUX
verify(project.plugins).apply(JBakePlugin::class.java)
// ✅ CORRECT
val (project, mockPluginContainer) = createMockProject()
verify(mockPluginContainer).apply(JBakePlugin::class.java)
2. Menghindari mock bersarang
// ❌ FAUX - UnfinishedStubbingException
val mockProject = mock<Project> {
on { logger } doReturn mock() // Nested mock creation !
}
// ✅ CORRECT - Créer séparément
val mockLogger = mock<org.gradle.api.logging.Logger>()
val mockProject = mock<Project>()
whenever(mockProject.logger).thenReturn(mockLogger)
3. Meniru callback evaluasi
// ✅ afterEvaluate doit s'exécuter pour les tests
whenever(mockProject.afterEvaluate(any())).doAnswer { invocation ->
val action = invocation.arguments[0] as Action<Project>
action.execute(mockProject)
null
}
4. Menguji resolusi jalur
// Toujours vérifier que les chemins se résolvent correctement
val extension = project.extensions.getByType(BakeryExtension::class.java)
val configPath = extension.configPath.get()
val projectDir = project.layout.projectDirectory.asFile
val resolvedConfig = projectDir.resolve(configPath)
println("Resolved config: ${resolvedConfig.absolutePath}")
println("Exists: ${resolvedConfig.exists()}")
Arsitektur pengujian akhir
@startuml
package "lapisan ujian" {
[Test Class] --> [createMockProject()]
}
package "Pembuatan Mock" {
[createMockProject()] --> [Create All Mocks]
[Create All Mocks] --> [Configure Paths]
[Configure Paths] --> [Configure Callbacks]
[Configure Callbacks] --> [Assemble Project]
}
package "Objek tiruan" {
[Assemble Project] --> [Project Mock]
[Assemble Project] --> [PluginContainer Mock]
[Assemble Project] --> [Extension Mocks]
[Assemble Project] --> [Layout Mocks]
}
package "Plugin yang sedang diuji" {
[Test Class] --> [BakeryPlugin]
[BakeryPlugin] --> [Project Mock]
[BakeryPlugin] --> [PluginContainer Mock]
}
package "verifikasi" {
[Test Class] --> [verify(mockPluginContainer)]
}
@enduml
Kesimpulan
Yang seolah-olah hanya sebuah masalah tes sederhana ternyata menjadi studi kasus yang sangat baik tentang :
-
Kehalusan Mockito dengan Kotlin
-
Pentingnya melakukan mock terhadap objek yang tepat
-
Pengelolaan callback asinkron dalam pengujian
-
Penyelesaian jalur dalam plugin Gradle
Debugging metodis, dengan memahami setiap lapisan masalah, memungkinkan untuk mencapai solusi yang kuat dan dapat dipelihara.
|
Tips untuk tes AndaJika Anda menemukan "Wanted but not invoked" dengan Mockito, selalu tanya pada diri sendiri : 1. Apakah saya sedang memeriksa mock yang benar? 2. Apakah semua mock saya dibuat di luar blok konfigurasi? 3. Apakah callback saya benar-benar dijalankan? 4. Apakah jalur saya diselesaikan dengan benar? |
Sumber daya
Anda pernah mengalami masalah serupa dalam tes Anda? Bagikan pengalaman Anda di komentar !