Maintainer Mockito mundur dari posisinya setelah 10 tahun

• Pemelihara inti Mockito mengumumkan bahwa per Maret 2026 ia akan mengakhiri sekitar 10 tahun peran pemeliharaan, dan berencana melakukan alih kewenangan secara bertahap dalam beberapa bulan ke depan
• Sebagai salah satu pemicu langsung keputusan ini, ia menyebut perubahan kebijakan agen di JVM 22. Meski ia sepakat dengan perubahan itu dari sisi keamanan, tuntutan transisi sepihak tanpa alternatif dan kurangnya pertimbangan pada level ekosistem menjadi beban besar
• Ia menjelaskan bahwa meskipun Mockito adalah salah satu pengguna terbesar agen JVM, struktur yang membuat proyek ini harus menanggung penyelesaian masalah tanpa dukungan build tool maupun diskusi kolaboratif berujung pada terkurasnya sumber daya dan beban tanggung jawab yang berlebihan
• Faktor lain yang ia soroti adalah kompleksitas struktural dukungan Kotlin. Ia menyatakan bahwa fitur-fitur yang tidak selaras dengan cara kerja JVM khas Kotlin telah meningkatkan API duplikat dan logika percabangan di dalam Mockito, sehingga pemeliharaan makin sulit
• Belakangan ini, ia merasakan kesenangan dan motivasi yang lebih besar saat mengerjakan web engine berbasis Rust, Servo, dan dengan mempertimbangkan keterbatasan waktu pribadi, ia sampai pada kesimpulan bahwa sulit untuk terus melanjutkan pekerjaan pemeliharaan sukarela yang terasa seperti kewajiban

---

Tonggak 10 tahun dan keputusan alih peran

• Pada Maret 2026, ia mencapai peringatan 10 tahun sebagai pemelihara Mockito, dan menilai momen itu sebagai titik percabangan alami untuk menyerahkan tanggung jawab
• Dalam beberapa bulan ke depan, ia berencana memfokuskan diri sebagai pemelihara lama pada transfer pengetahuan dan stabilisasi transisi
• Diskusi mengenai sistem pemeliharaan berikutnya dan roadmap jangka panjang akan dilakukan di GitHub issue terpisah

Keletihan akibat perubahan kebijakan agen JVM

• Latar belakang artifact default beralih menjadi agen JVM di Mockito 5 adalah perubahan kebijakan sejak JVM 22 yang menyembunyikan dynamic agent attachment di balik flag
• Ia setuju dengan arah perubahan dari sudut pandang keamanan, tetapi mengkritik ditetapkannya keputusan itu sebagai sesuatu yang sudah final tanpa desain alternatif maupun dukungan migrasi
• Meskipun Mockito sering digunakan sebagai contoh terdepan untuk fitur JVM, pada perubahan kali ini loop umpan balik kolaboratif tidak berjalan
• Ia menilai bahwa dukungan pada level build tool untuk agen yang masih kurang menunjukkan rendahnya prioritas terhadap fitur tersebut
• Ia menekankan bahwa bila tekanan berlebihan dibebankan kepada pemelihara yang berkontribusi secara sukarela, struktur kolaborasi open source dapat dengan mudah runtuh

Beban struktural yang ditimbulkan dukungan Kotlin

• Ia tidak memandang negatif meluasnya Kotlin, tetapi karena perbedaan cara kerja internal JVM, banyak alur penanganan khusus Kotlin ditambahkan ke mockito-core
• Ada kasus di mana fitur Kotlin seperti suspend function tidak berjalan secara konsisten, sehingga duplikasi API dan kompleksitas meningkat
• Akibatnya, codebase menjadi makin menyerupai spaghetti code dan tingkat kesulitan pemeliharaan meningkat, dan ia secara jujur menyebut pekerjaan ini tidak menyenangkan baginya secara pribadi
• Masa depan yang makin berpusat pada Kotlin menjadi faktor yang dalam jangka panjang melemahkan motivasinya untuk memelihara Mockito

Memulihkan kembali kesenangan dari aktivitas open source lain

• Ia telah berkontribusi ke banyak proyek open source, dan belakangan ini kembali merasakan kesenangan dalam pengembangan melalui pekerjaan pada web engine berbasis Rust, Servo
• Di tengah pilihan waktu malam yang terbatas, proyek lain memberi kepuasan lebih besar dibanding Mockito dan kondisi ini terus berlanjut
• Ia menilai bahwa pekerjaan pemeliharaan berbasis sukarela yang dalam jangka panjang terasa seperti kewajiban bukanlah keadaan yang ideal

Latar belakang menyeluruh keputusan ini dan pesannya

• Rasa skeptis akibat perubahan kebijakan JVM, keterbatasan struktur dukungan Kotlin, dan pulihnya motivasi dari proyek lain menjadi faktor utama keputusan ini
• Ia mengakui bahwa faktor-faktor tersebut tidak selalu berlaku sama bagi semua kontributor, dan orang lain bisa saja lebih proaktif dalam dukungan Kotlin
• Ia memutuskan untuk melepaskan peran itu dengan keyakinan bahwa pergantian pemelihara lebih bermanfaat bagi kesehatan jangka panjang proyek
• Ia menilai pengalaman sebagai pemelihara open source sendiri sebagai kehormatan dan privilese, serta mendorong orang lain untuk ikut memberi kontribusi sukarela

[GN⁺]

Komentar Hacker News

• Saat mengerjakan proyek kedua di Google, saya akhirnya meninggalkan mocking sepenuhnya
  Ketika menulis ulang sistem dengan GWT, pengujian coverage diwajibkan, tetapi semua orang hanya menguji layanannya sendiri dan menyuntikkan mock lewat DI
  Akibatnya, sistem menjadi sangat rapuh, dan layanan yang baru berumur 8 minggu sudah terasa seperti kode legacy. Hanya dengan mengubah urutan backend atau jumlah pemanggilan saja, kami bisa seharian sibuk memperbaiki mock
  Struktur modul Guice juga rumit, jadi untuk menyuntikkan mock bagi lingkungan pengujian kami harus membuat injector yang benar-benar berbeda, dan pada akhirnya lingkungan test dan production menjadi berbeda
  Selain itu, banyak sekali sumber daya engineering terbuang untuk perdebatan EasyMock vs Mockito
  Sejak itu saya hampir tidak pernah memakai mock. Sebagai gantinya, saya merasa jauh lebih baik membuat layanan dummy sederhana yang meniru perilaku nyata seminimal mungkin
  Sampai sekarang pun saya jadi waspada kalau melihat orang terlalu terobsesi dengan mock

  • Kalau yang dimaksud adalah “versi dummy yang melakukan perilaku minimum yang benar”, bukankah itu justru definisi mock?
  • Jika dummy seperti itu tidak diimplementasikan sebagai mock, berarti Anda menggunakan mock dengan cara yang salah
  • Saya juga sampai pada kesimpulan serupa di Google. Dalam kebanyakan kasus, fake lebih baik daripada mock. Namun, jika tidak berada di lingkungan seperti Google yang memberi akses ke semua source code, ada kalanya mock memang diperlukan
  • Saya hanya memakai Mockito dalam situasi yang benar-benar tak terhindarkan, seperti refactoring kode legacy atau menguji library eksternal. Itu sama sekali bukan pilihan pertama
  • Penyalahgunaan mock berasal dari salah paham terhadap “test pyramid”. Karena hanya menekankan unit test, jadilah banyak test yang rapuh dan bernilai rendah. AI yang otomatis membuat test seperti ini malah memperburuk keadaan

• Saya sudah memakai Mockito selama 4 tahun di Kotlin, dan dalam 99% kasus itu cukup layak dipakai
  Situasi yang rumit atau membingungkan kebanyakan muncul karena kurangnya pemisahan concern dalam kode saya
  Perbedaannya dengan MockK hampir tidak ada, hanya soal sintaks saja. Namun, jika Mockito berhenti dipelihara, saya mungkin akan mempertimbangkan penggantinya

  • Melihat perdebatan seperti ini justru terasa seperti bukti bahwa proyeknya berhasil. Untuk pengembang yang telah mendedikasikan diri lebih dari 10 tahun, sebuah toast terima kasih
  • Ini tampaknya lebih seperti arus alami untuk berpindah ke Kotlin dan Rust, bukan kemarahan
  • Saya rasa sejak awal dukungan Kotlin seharusnya ditolak. Akan lebih baik kalau ada framework khusus Kotlin yang terpisah
  • Masalahnya bukan pada alatnya sendiri. Mock dan spy terlalu mudah digunakan, sehingga orang jadi tidak merancang struktur test dengan benar

• Mock paling efektif ketika aplikasi memiliki 4~5 lapisan
  Dulu saya juga berlebihan memakai DI sampai membangun jaring kode yang kompleks, tetapi sekarang saya membatasi lapisan dan menjaga strukturnya tetap konsisten
  Untuk pengujian kelas tunggal saya memakai mock, dan untuk verifikasi requirement saya memakai integration test
  Pada akhirnya yang penting bukan alatnya, melainkan disiplin pengembang

• Mockito adalah framework mocking paling populer di Java

  • Tetapi setelah mengalami neraka test yang dibuat dengannya, saya merasa seperti umur saya terkikis
  • Dalam bahasa Spanyol artinya “upil kecil”, jadi namanya agak lucu

• Karena perubahan platform, Mockito beralih menjadi berbasis agent, karena mulai JVM 22 pemuatan agent dinamis disembunyikan di balik flag
  Perubahan seperti ini bisa memperlambat adopsi di enterprise

  • Ini hanya soal menambahkan flag saat menjalankan test
  • Bagaimanapun, kebanyakan perusahaan masih sedang berpindah dari Java 8 ke 17, jadi JVM 22 masih cerita yang lama lagi

• Perubahan platform ini terasa seperti pelimpahan tanggung jawab yang berlebihan kepada komunitas Mockito
  Saya rasa tuduhan seperti “menghambat ekosistem JVM” tidak sehat

  • Namun tim JDK sudah mengumumkan perubahan ini sejak bertahun-tahun lalu. Dengan menambahkan sedikit konfigurasi, fitur dinamis itu tetap bisa dipakai, dan ini adalah pilihan yang tepat demi optimisasi platform dan keamanan

• Memelihara open source benar-benar terlihat sebagai pekerjaan yang menguras tenaga
  Kalau saya, mungkin sudah saya arsipkan saja dan saya tinggalkan. Semoga Tim akhirnya bisa menemukan ketenangan

  • Meski begitu, saya rasa ini adalah perpisahan yang tetap bermartabat. Saya menghormati usaha yang telah dicurahkan begitu lama, dan pencapaian Tim akan selalu layak dibanggakan

• Saya ingin menyampaikan terima kasih kepada TimvdLippe. Ia menunjukkan visi dan dedikasi yang luar biasa

• Mockito tidak masalah jika dipakai oleh orang yang benar-benar paham testing
  Di bahasa atau framework mana pun, test yang buruk adalah salah penulisnya

• “Agent” adalah alat yang terpasang pada JVM dan dapat menginstrumentasi serta mengubah aplikasi yang sedang berjalan
  Profiler, debugger, dan tool monitoring menggunakan mekanisme ini
  Sejak Java 21, fitur ini dinonaktifkan secara default demi memperkuat keamanan, dan hanya diizinkan lewat flag -XX:+EnableDynamicAgentLoading
  Untuk detail lebih lanjut, lihat dokumen JEP 451

  • Dokumen yang sama, JEP 451: Prepare to Disallow the Dynamic Loading of Agents, menjelaskan latar belakangnya
  • Dulu debugger bisa dihubungkan lewat port saat runtime, tetapi karena masalah keamanan sekarang agent harus didaftarkan secara eksplisit saat startup