Mockito bakım sorumlusu 10 yılın ardından görevinden ayrılıyor

• Mockito'nun çekirdek bakım sorumlusu, Mart 2026 itibarıyla yaklaşık 10 yıllık bakım sorumluluğunu tamamlayacağını ve önümüzdeki birkaç ay içinde kademeli bir yetki devri gerçekleştireceğini açıkladı
• Kararın doğrudan tetikleyicilerinden biri olarak JVM 22'deki ajan politikası değişikliğini gösterdi; güvenlik amacıyla yapılan değişikliği anlayışla karşılasa da alternatifsiz tek taraflı geçiş talebi ve ekosistem düzeyinde yeterli değerlendirme yapılmaması büyük bir yük oluşturdu
• Özellikle Mockito, JVM ajanlarının en büyük kullanıcılarından biri olmasına rağmen, build aracı desteği veya işbirlikçi tartışmalar olmadan sorunun çözümünü üstlenmek zorunda kalan yapının kaynak tükenmesine ve aşırı sorumluluk yüküne yol açtığını anlattı
• Bir diğer etken olarak Kotlin desteğinin yapısal karmaşıklığını işaret ederek, Kotlin'e özgü JVM çalışma biçimiyle örtüşmeyen özelliklerin Mockito içinde tekrarlanan API'ler ve dallanan mantığı artırdığını, bunun da bakımı zorlaştırdığını belirtti
• Son dönemde Rust tabanlı web motoru Servo üzerinde çalışırken daha fazla keyif ve motivasyon bulduğunu, sınırlı kişisel zamanı düşünüldüğünde zorunluluk gibi hissettiren gönüllü bakım işini sürdürmenin zorlaştığı sonucuna vardığını paylaştı

---

10 yıllık dönüm noktası ve görev devri kararı

• Mart 2026'da Mockito bakımının 10. yılına ulaşırken, bu zamanı sorumluluğu devretmek için doğal bir dönüm noktası olarak gördüğünü belirtti
• Önümüzdeki birkaç ay boyunca mevcut bakım sorumlusu olarak bilgi aktarımı ve geçişin istikrarlı biçimde sürmesine odaklanmayı planlıyor
• Sonraki bakım yapısı ve uzun vadeli yol haritasına ilişkin tartışmaların ayrı bir GitHub issue'sunda yürütüleceği ifade edildi

JVM ajan politikası değişikliğinin yarattığı tükenmişlik

• Mockito 5'te varsayılan artifact'in JVM ajanına dönüştürülmesinin arkasında, JVM 22'den itibaren dinamik ajan eklemenin bir flag arkasına gizlenmesiyle gelen politika değişikliği bulunuyor
• Güvenlik açısından değişikliğin amacına katılsa da alternatif tasarım veya geçiş desteği olmadan kararın fiilen dayatılmış olması sorun olarak öne çıkarıldı
• Mockito, JVM özellikleri için sık sık öncü örnek olarak kullanılmış olmasına rağmen, bu değişimde işbirliğine dayalı geri bildirim döngüsünün işlemediği belirtildi
• Ajanlara yönelik build araçları düzeyindeki desteğin hâlâ yetersiz olması, bu özelliğin önceliğinin düşük görüldüğünü gösteriyor şeklinde değerlendirildi
• Gönüllü katkı sunan bakım sorumlularına aşırı baskı yüklendiğinde açık kaynak işbirliği yapısının kolayca çözülebileceği vurgulandı

Kotlin desteğinin yarattığı yapısal yük

• Kotlin'in yaygınlaşmasını olumsuz görmediğini, ancak JVM iç davranışındaki farklılıklar nedeniyle mockito-core'a Kotlin'e özel çok sayıda işleme akışı eklendiğini söyledi
• suspend fonksiyonlar gibi Kotlin özelliklerinin tutarlı biçimde çalışmadığı örnekler bulunduğu, bunun da API tekrarını ve karmaşıklığı artırdığı aktarıldı
• Sonuç olarak kod tabanının spagetti hâline geldiği ve bakım zorluğunun arttığı, ayrıca bu tür çalışmaların kişisel olarak keyif vermediği açıkça dile getirildi
• Kotlin merkezli geleceğin uzun vadede Mockito bakım motivasyonunu zayıflatan bir unsur olduğu ifade edildi

Diğer açık kaynak faaliyetlerinde yeniden keyif bulmak

• Çok sayıda açık kaynak projeye katkı sunduğunu, son dönemde ise Rust tabanlı web motoru Servo üzerinde çalışırken geliştirme keyfini yeniden hissettiğini söyledi
• Sınırlı akşam saatlerini nasıl değerlendireceği konusunda, Mockito'ya kıyasla başka projelerin daha fazla tatmin sağladığı bir durumun sürdüğü belirtildi
• Gönüllülük esaslı bakım işlerinin uzun süre bir zorunluluk gibi hissedilmesinin sağlıklı olmadığına karar verdiğini paylaştı

Kararın bütünsel arka planı ve mesajı

• JVM politika değişikliğinin yarattığı hayal kırıklığı, Kotlin desteğinin yapısal sınırları ve diğer projelerde motivasyonun yeniden bulunması kararın temel nedenleri olarak gösterildi
• Bu etkenlerin tüm katkıcılar için aynı şekilde geçerli olmadığını, başkalarının Kotlin desteğine daha istekli yaklaşabileceğini kabul etti
• Bakım sorumlusunun değişmesinin projenin uzun vadeli sağlığı açısından daha faydalı olacağı değerlendirmesiyle görevi bırakma kararı aldı
• Açık kaynak bakım deneyimini bir onur ve ayrıcalık olarak nitelendirirken, başkalarını da gönüllü katkıda bulunmaya teşvik etti

[GN⁺]

Hacker News görüşleri

• Google'da ikinci projem üzerinde çalışırken mocking yaklaşımını tamamen bırakmaya karar verdim
  GWT ile sistemi yeniden yazarken test kapsamını zorunlu kılmıştık; herkes yalnızca kendi servisini test ediyor ve DI ile mock enjekte ediyordu
  Sonuç olarak sistem aşırı kırılgan hale geldi ve 8 haftalık servis bile sanki legacy code gibi hissettiriyordu. Backend sırasını ya da çağrı sayısını değiştirmek bile bütün gün mock düzeltmekle uğraşmaya yol açıyordu
  Guice modül yapısı da karmaşıktı; test ortamı için mock enjekte etmek üzere tamamen farklı bir injector oluşturmak gerekiyordu ve sonunda test ile production farklı ortamlara dönüşüyordu
  Ayrıca EasyMock vs Mockito tartışmaları yüzünden sayısız mühendislik kaynağı boşa harcandı
  O günden beri neredeyse hiç mock kullanmıyorum. Bunun yerine basit dummy servisler yapıp asgari gerçek davranışı taklit etmenin çok daha iyi olduğunu düşünüyorum
  Mock'a takıntılı insanları görünce hâlâ temkinli oluyorum

  • “Asgari düzeyde doğru davranan bir dummy sürüm” ise, bu zaten mock'un tanımı değil mi diye düşünüyorum
  • Böyle bir dummy'yi mock olarak uygulamıyorsan, o zaman mock'u yanlış kullanıyorsundur
  • Ben de Google'da benzer bir sonuca vardım. Çoğu durumda fake, mock'tan daha iyi diye düşünüyorum. Yine de Google gibi tüm kaynak koduna erişebildiğiniz bir ortam yoksa mock gereken durumlar olabilir
  • Mockito'yu sadece legacy code refactoring ya da harici kütüphane testleri gibi mecburi durumlarda kullandım. Asla ilk tercih değil
  • Mock'un aşırı kullanımı, “test piramidi”nin yanlış anlaşılmasından kaynaklanıyor. Unit test'lere aşırı vurgu yapılınca kırılgan ve düşük değerli testler üretiliyor. Yapay zekanın bu testleri otomatik üretmesiyle durum daha da kötüleşiyor

• Kotlin'de 4 yıldır Mockito kullanıyorum ve vakaların %99'unda gayet yeterliydi
  Karmaşık ya da kafa karıştırıcı durumların çoğu aslında ilgi alanlarını yeterince ayırmamamdan kaynaklanıyordu
  MockK ile farkı neredeyse yok; daha çok sözdizimi farkı gibi. Yine de Mockito'nun bakımı bırakılırsa değiştirmeyi düşünebilirim

  • Bu tür tartışmaları görünce tam tersine projenin başarılı olduğunun göstergesi gibi geliyor. 10 yılı aşkın süredir emek veren geliştiriciye şükran kadehi kaldırıyorum
  • Bu daha çok öfkeden ziyade, Kotlin ve Rust'a geçişte görülen doğal bir akış gibi duruyor
  • Bence en baştan Kotlin desteğini reddetmeleri gerekirdi. Kotlin'e özel ayrı bir framework olsaydı daha iyi olurdu
  • Sorun aracın kendisi değil. Mock ve spy o kadar rahat ki, test yapısını düzgün tasarlamamaya yol açmaları asıl problem

• Mock'lar, uygulama 4-5 katmanlı olduğunda en etkili oluyor
  Ben de eskiden DI'yi aşırı kullanıp karmaşık bir kod ağı oluşturmuştum, ama artık katman sayısını sınırlıyor ve tutarlı bir yapı koruyorum
  Tek sınıf testlerinde mock, gereksinim doğrulamada ise entegrasyon testleri kullanıyorum
  Sonuçta önemli olan araç değil, geliştiricinin disiplini

• Mockito, Java'daki en popüler mocking framework'ü

  • Ama bununla oluşturulmuş test cehennemini yaşayınca ömrümden yediğini hissettirdi
  • İspanyolcada “küçük sümük” anlamına geliyor, bu yüzden adı biraz komik

• Platform değişikliği nedeniyle Mockito agent tabanlı hale geldi; çünkü JVM 22'den itibaren dinamik agent yükleme bir flag'in arkasına alındı
  Bu tür bir değişiklik enterprise benimsemeyi yavaşlatabilir

  • Sadece test çalıştırırken flag eklemek yeterli
  • Zaten çoğu şirket hâlâ Java 8'den 17'ye geçmeye çalışıyor; JVM 22 daha çok uzak bir mesele

• Platform değişikliğinin Mockito topluluğuna aşırı sorumluluk yüklenmesi gibi hissettirdiğini düşündüm
  “JVM ekosistemini engelliyorlar” tarzı suçlamaların sağlıklı olmadığını düşünüyorum

  • Ama JDK ekibi bu değişikliği yıllar öncesinden duyurmuştu. Biraz ayar ekleyerek dinamik yetenekler hâlâ kullanılabiliyor ve bu, platform optimizasyonu ve güvenlik için doğru bir tercih

• Açık kaynak bakım işi gerçekten yıpratıcı görünüyor
  Ben olsam muhtemelen projeyi arşivler ve tamamen çekilirdim. Tim'in en azından şimdi huzur bulmasını umuyorum

  • Yine de bunun vakur bir ayrılış olduğunu düşünüyorum. Bunca yıllık emeğe saygı duyuyorum; Tim'in başardıkları sonsuza kadar gurur verici olacak

• TimvdLippe'e teşekkür etmek istiyorum. Harika bir vizyon ve bağlılık gösterdi

• Mockito, testi iyi bilen biri kullandığında gayet iyi olabilir
  Hangi dil ya da framework olursa olsun, kötü testlerin suçu yazan kişidedir

• “Agent”, JVM'e bağlanıp çalışan uygulamayı enstrümante edebilen ve değiştirebilen bir aracı ifade eder
  Profiler'lar, debugger'lar ve monitoring araçları bu mekanizmayı kullanır
  Java 21'den itibaren güvenliği artırmak için varsayılan olarak devre dışı bırakıldı ve yalnızca -XX:+EnableDynamicAgentLoading flag'i ile izin veriliyor
  Ayrıntılar için JEP 451 belgesine bakılabilir

  • Aynı belgede JEP 451: Prepare to Disallow the Dynamic Loading of Agents başlığı altında arka plan açıklaması da var
  • Eskiden çalışma sırasında bir debugger'ı porta bağlayabiliyordunuz, ama güvenlik sorunları nedeniyle artık agent'ı başlangıçta açıkça kaydetmek gerekiyor