Mockito मेंटेनर 10 साल बाद पद से हटेंगे

• Mockito के मुख्य मेंटेनर ने बताया कि वे मार्च 2026 तक लगभग 10 साल की मेंटेनेंस भूमिका पूरी कर लेंगे और आने वाले कुछ महीनों में धीरे-धीरे अधिकार हस्तांतरण करेंगे
• इस फैसले के सीधे कारणों में से एक के रूप में उन्होंने JVM 22 में एजेंट पॉलिसी बदलाव का ज़िक्र किया। सुरक्षा उद्देश्य वाले इस बदलाव से वे सहमत हैं, लेकिन बिना विकल्प के एकतरफा ट्रांज़िशन की मांग और ecosystem-स्तरीय विचार की कमी को बड़ा बोझ बताया
• खासकर Mockito, JVM एजेंट के सबसे बड़े उपयोगकर्ताओं में से एक होने के बावजूद, build tool support या सहयोगी चर्चा के बिना समस्या सुलझाने की ज़िम्मेदारी उसी पर आ गई, जिससे संसाधनों की थकावट और ज़िम्मेदारी का अत्यधिक बोझ पैदा हुआ
• एक अन्य कारण के रूप में उन्होंने Kotlin support की संरचनात्मक जटिलता की ओर इशारा किया और बताया कि Kotlin के JVM पर काम करने के अलग तरीके के कारण Mockito के अंदर डुप्लिकेट API और branching logic बढ़ते गए, जिससे maintenance कठिन हो गई
• हाल के समय में उन्हें Rust-आधारित web engine Servo पर काम करने में अधिक खुशी और प्रेरणा मिल रही है, और सीमित निजी समय को देखते हुए वे इस निष्कर्ष पर पहुँचे कि कर्तव्य जैसा लगने वाला volunteer maintenance work जारी रखना मुश्किल है

---

10 साल का माइलस्टोन और भूमिका हस्तांतरण का फैसला

• मार्च 2026 में Mockito maintenance के 10 साल पूरे होने पर उन्होंने इसे ज़िम्मेदारी हस्तांतरण के लिए एक स्वाभाविक मोड़ माना
• आने वाले कुछ महीनों में वे मौजूदा मेंटेनर के रूप में knowledge transfer और transition stabilization पर ध्यान देंगे
• अगली maintenance व्यवस्था और long-term roadmap पर चर्चा अलग GitHub issue में की जाएगी

JVM एजेंट पॉलिसी बदलाव से आई थकावट

• Mockito 5 में default artifact को JVM एजेंट में बदलने की पृष्ठभूमि JVM 22 से dynamic agent attachment को flag के पीछे छिपा देने वाली policy change है
• वे इस बदलाव के security उद्देश्य से सहमत हैं, लेकिन alternative design या migration support के बिना फैसले को लगभग तय मान लेने को समस्या बताते हैं
• Mockito लंबे समय से JVM फीचर्स के अग्रणी उपयोग के उदाहरण के रूप में इस्तेमाल होता रहा है, फिर भी इस बदलाव में collaborative feedback loop काम नहीं कर सका
• उनका आकलन है कि एजेंट के लिए build tool स्तर पर support अब भी कमज़ोर है, जो दिखाता है कि इस फीचर की प्राथमिकता कम है
• उन्होंने ज़ोर देकर कहा कि यदि स्वैच्छिक योगदान देने वाले मेंटेनर पर अत्यधिक दबाव डाला जाए तो open source collaboration structure आसानी से टूट सकती है

Kotlin support से पैदा हुआ संरचनात्मक बोझ

• वे Kotlin के प्रसार को नकारते नहीं हैं, लेकिन JVM के अंदरूनी व्यवहार में अंतर के कारण mockito-core में Kotlin-विशेष processing flow की बड़ी संख्या जुड़ गई
• suspend functions जैसी Kotlin सुविधाओं के लगातार एक जैसा काम न करने के उदाहरण हैं, जिससे API duplication और complexity बढ़ी
• नतीजतन codebase spaghetti जैसा होता गया और maintenance की कठिनाई बढ़ी, और उन्होंने साफ कहा कि इस तरह का काम उन्हें व्यक्तिगत रूप से आनंद नहीं देता
• Kotlin-केंद्रित भविष्य ने लंबे समय में Mockito maintenance के लिए उनकी प्रेरणा को कमज़ोर करने वाला कारक के रूप में काम किया

दूसरे open source कामों में फिर से मिली खुशी

• वे कई open source projects में योगदान देते रहे हैं, और हाल में Rust-आधारित web engine Servo पर काम करते हुए उन्हें विकास का आनंद फिर से महसूस हुआ
• शाम के सीमित निजी समय में Mockito की तुलना में दूसरे projects अधिक संतोष दे रहे हैं
• उन्होंने माना कि volunteer-based maintenance work का लंबे समय तक कर्तव्य जैसा महसूस होना स्वस्थ स्थिति नहीं है

फैसले की समग्र पृष्ठभूमि और संदेश

• JVM policy changes से आई निराशा, Kotlin support structure की सीमाएँ, और दूसरे projects में प्रेरणा की वापसी इस फैसले के मुख्य कारण रहे
• उन्होंने माना कि ये कारण सभी contributors पर एक समान लागू नहीं होते, और दूसरे लोग Kotlin support को अधिक उत्साह से आगे बढ़ा सकते हैं
• उन्होंने निष्कर्ष निकाला कि मेंटेनर बदलना project की long-term health के लिए अधिक फायदेमंद होगा, इसलिए वे भूमिका छोड़ेंगे
• उन्होंने open source maintenance के अनुभव को सम्मान और विशेषाधिकार बताया, और दूसरों को भी स्वैच्छिक योगदान के लिए प्रोत्साहित किया

[GN⁺]

Hacker News की राय

• Google में दूसरा प्रोजेक्ट करते समय मैंने mocking को पूरी तरह छोड़ दिया
  GWT के साथ सिस्टम को rewrite करते हुए test coverage अनिवार्य किया गया था, लेकिन हर कोई सिर्फ अपनी service को test कर रहा था और DI से mock inject कर रहा था
  नतीजा यह हुआ कि सिस्टम बेहद नाज़ुक हो गया, और 8 हफ्ते पुरानी service भी legacy code जैसी लगने लगी
  backend में order या call count बदलने भर से पूरा दिन mock ठीक करने में निकल जाता था
  Guice module structure भी इतना जटिल था कि test environment के लिए mock inject करने हेतु पूरी तरह अलग injector बनाना पड़ता था, और आखिरकार test और production अलग-अलग environment बन गए
  ऊपर से EasyMock vs Mockito बहस में भी बहुत सारे engineering resources बर्बाद हुए
  तब से मैं लगभग mock का इस्तेमाल नहीं करता
  इसकी जगह सरल dummy services बनाकर कम-से-कम असली behavior की नकल करना मुझे कहीं बेहतर लगता है
  आज भी जो लोग mock पर ज़रूरत से ज़्यादा ज़ोर देते हैं, उन्हें देखकर सतर्क हो जाता हूँ

  • अगर “कम-से-कम सही behavior वाला dummy version” है, तो क्या वही mock की परिभाषा नहीं है?
  • अगर ऐसे dummy को mock के रूप में implement नहीं किया जा रहा, तो mock का गलत इस्तेमाल हो रहा है
  • मैंने भी Google में इसी तरह का निष्कर्ष निकाला था
    ज़्यादातर मामलों में fake, mock से बेहतर होता है
    हाँ, Google जैसे ऐसे environment के बाहर जहाँ हर source तक access नहीं होता, mock की ज़रूरत पड़ सकती है
  • मैंने Mockito का इस्तेमाल सिर्फ legacy code refactoring या external library testing जैसी मजबूरी वाली स्थितियों में किया है
    यह कभी पहली पसंद नहीं रही
  • mock का overuse “test pyramid” की गलत समझ से आता है
    unit test पर ज़रूरत से ज़्यादा ज़ोर देने से नाज़ुक और कम-मूल्य वाले test बड़ी संख्या में बनते हैं
    AI ऐसे test अपने-आप generate करके स्थिति को और बिगाड़ रहा है

• मैंने Kotlin में 4 साल तक Mockito इस्तेमाल किया है, और 99% मामलों में यह काफ़ी उपयोगी रहा
  जटिल या उलझाऊ स्थितियाँ ज़्यादातर मेरे concern separation की कमी की वजह से थीं
  MockK से फ़र्क लगभग नहीं के बराबर है, बस syntax का अंतर है
  लेकिन अगर Mockito का maintenance रुक जाता है, तो शायद इसे बदलने पर विचार करना पड़े

  • ऐसी बहसें देखकर तो उल्टा लगता है कि project सफल रहा
    10 साल से ज़्यादा समर्पण देने वाले developer के नाम आभार का जाम होना चाहिए
  • यह ग़ुस्से से ज़्यादा Kotlin और Rust की ओर बढ़ने वाला एक स्वाभाविक बदलाव लगता है
  • मेरा मानना है कि शुरू से Kotlin support ठुकरा देना चाहिए था
    Kotlin के लिए अलग framework होता तो बेहतर रहता
  • समस्या tool की नहीं है
    mock और spy इतने आसान हैं कि लोग test structure को सही ढंग से design ही नहीं करते, असली समस्या यह है

• mock तब सबसे असरदार होते हैं जब application 4~5 layers में बँटी हो
  मैं भी पहले DI का ज़रूरत से ज़्यादा इस्तेमाल करके जटिल code web बना चुका हूँ, लेकिन अब layers सीमित रखता हूँ और structure को consistent रखता हूँ
  single class test के लिए mock, और requirements verify करने के लिए integration test इस्तेमाल करता हूँ
  आखिरकार अहम चीज़ tool नहीं, बल्कि developer का discipline है

• Mockito, Java का सबसे लोकप्रिय mocking framework है

  • लेकिन इससे बने हुए test hell से गुज़रते हुए लगा कि उम्र कम हो रही है
  • Spanish में इसका मतलब “छोटी booger” होता है, इसलिए नाम थोड़ा मज़ेदार लगता है

• platform बदलाव के कारण Mockito agent-based हो गया है, क्योंकि JVM 22 से dynamic agent loading को एक flag के पीछे छिपा दिया गया है
  ऐसे बदलाव enterprise adoption को धीमा कर सकते हैं

  • बस test चलाते समय एक flag जोड़ना होता है
  • वैसे भी ज़्यादातर कंपनियाँ अभी Java 8 से 17 पर जाने में लगी हैं, इसलिए JVM 22 की बात अभी काफ़ी दूर है

• platform बदलाव को Mockito community पर ज़रूरत से ज़्यादा ज़िम्मेदारी डालने जैसा महसूस किया गया
  “यह JVM ecosystem को रोक रहा है” जैसी आलोचना मुझे स्वस्थ नहीं लगती

  • लेकिन JDK team कई साल पहले से ऐसे बदलावों की चेतावनी दे रही थी
    थोड़ी-सी configuration जोड़कर dynamic features अब भी इस्तेमाल किए जा सकते हैं, और यह platform optimization और security के लिए सही फ़ैसला है

• open source maintenance सच में बहुत थका देने वाला काम लगता है
  मैं होता तो बस archive करके हाथ खींच लेता
  उम्मीद है Tim को अब कुछ सुकून मिलेगा

  • फिर भी मुझे लगता है कि यह गरिमा के साथ विदाई थी
    इतने लंबे समय तक किए गए प्रयास का सम्मान होना चाहिए, और Tim की उपलब्धियाँ हमेशा गर्व की बात रहेंगी

• मैं TimvdLippe को धन्यवाद कहना चाहता हूँ
  उन्होंने शानदार vision और dedication दिखाया

• Mockito उस व्यक्ति के हाथ में ठीक है जो testing को अच्छी तरह समझता हो
  किसी भी language या framework में खराब test की ज़िम्मेदारी उसके लेखक की होती है

• “Agent” वह tool है जो JVM से attach होकर चल रहे application को instrument या modify कर सकता है
  profiler, debugger, monitoring tools आदि इसी mechanism का इस्तेमाल करते हैं
  Java 21 से security मज़बूत करने के लिए यह default रूप से disabled है, और सिर्फ -XX:+EnableDynamicAgentLoading flag के साथ ही allowed है
  अधिक जानकारी के लिए JEP 451 दस्तावेज़ देखें

  • उसी दस्तावेज़ JEP 451: Prepare to Disallow the Dynamic Loading of Agents में पृष्ठभूमि समझाई गई है
  • पहले runtime के दौरान debugger को port से जोड़ा जा सकता था, लेकिन security कारणों से अब startup के समय agent को स्पष्ट रूप से register करना पड़ता है