Mockitoメンテナーが10年ぶりにその役職を退く

• Mockitoの中核メンテナーが、2026年3月をもって約10年間のメンテナー役割を終え、今後数か月かけて段階的な権限移譲を進める計画を明らかにした
• 決定の直接的なきっかけの一つとしてJVM 22におけるエージェント方針の変更を挙げており、セキュリティ目的の変更自体には共感する一方で、代替策のない一方的な移行要求とエコシステム全体への配慮不足が大きな負担として作用した
• 特に、MockitoがJVMエージェントの最大級の利用者の一つであるにもかかわらず、ビルドツール側の支援や協調的な議論なしに問題解決を引き受ける構図が、リソース消耗と責任過多につながったと説明した
• また別の要因としてKotlin対応の構造的な複雑さを指摘し、Kotlin特有のJVM動作方式と噛み合わない機能がMockito内部で重複APIや分岐ロジックを増やし、保守を難しくしていると述べた
• 最近はRustベースのWebエンジンServoでの作業により大きな楽しさと動機を感じており、限られた個人時間を考えると、義務のように感じられるボランティアのメンテナンス作業を続けるのは難しいとの判断に至ったことを共有した

---

10年という節目と役割移譲の決定

• 2026年3月でMockitoメンテナンス10周年を迎えるにあたり、その時点を自然な責任移譲の節目と判断した
• 今後数か月は既存メンテナーとして知識移転と移行の安定化に注力する計画である
• 次期メンテナー体制と長期ロードマップの議論は、別途GitHub Issueで進める予定である

JVMエージェント方針変更による消耗

• Mockito 5でデフォルトアーティファクトがJVMエージェントへ移行した背景には、JVM 22から動的エージェント添付がフラグの背後に隠されたという方針変更がある
• セキュリティ観点での変更趣旨には同意する一方、代替設計や移行支援なしに決定が既成事実化された点が問題だと指摘した
• MockitoはこれまでJVM機能の先行事例としてしばしば活用されてきたにもかかわらず、今回の変更では協調的なフィードバックループが機能しなかった
• エージェントに対するビルドツールレベルの支援が依然として不十分な現実は、この機能の優先順位が低いことを示していると評価した
• 自発的貢献者であるメンテナーに過度な圧力がかかると、オープンソースの協業構造は容易に崩れることを強調した

Kotlin対応がもたらした構造的負担

• Kotlinの普及自体を否定しているわけではないが、JVM内部動作の違いにより、mockito-coreにはKotlin専用の処理フローが多数追加された
• suspend関数などのKotlin機能に一貫して動作しないケースが存在し、APIの重複と複雑性が増した
• 結果としてコードベースはスパゲッティ化し、保守難易度が上昇しており、その作業は個人的に楽しくないと率直に述べた
• Kotlin中心の未来は、長期的にMockitoを保守する動機を弱める要素として作用した

他のオープンソース活動で楽しさを取り戻す

• 多くのオープンソースプロジェクトに貢献してきており、最近はRustベースのWebエンジンServoでの作業を通じて開発の楽しさを再び感じている
• 限られた夜の時間の使い道として、Mockitoよりも他のプロジェクトのほうが大きな満足を与えてくれる状況が続いている
• ボランティアベースのメンテナンス作業が長期間にわたり義務のように感じられる状態は望ましくないと判断した

決定の総合的背景とメッセージ

• JVM方針変更による幻滅感、Kotlin対応構造の限界、そして他プロジェクトでの動機回復が決定の核心要因として作用した
• これらの要因がすべての貢献者に同じように当てはまるわけではなく、他の人々はKotlin対応により積極的かもしれないことも認めた
• メンテナー交代がプロジェクトの長期的な健全性にとってより有益だとの判断のもと、役割を手放すことにした
• オープンソースのメンテナンス経験そのものは栄誉であり特権だったと評価し、他の人々にもボランティア的な貢献を勧めた

[GN⁺]

Hacker Newsのコメント

• Googleで2つ目のプロジェクトに取り組んだとき、mockingを完全にやめるようになった。
  GWTでシステムを書き直す際にテストカバレッジを強制したところ、全員が自分のサービスだけをテストし、DIでmockを注入していた。
  その結果、システムは極端にもろくなり、8週間しか経っていないサービスなのにまるでレガシーコードのように感じられた。バックエンドの順序や呼び出し回数を変えるだけで、丸一日mockの修正に追われることもあった。
  Guiceのモジュール構造も複雑で、テスト環境向けのmockを注入するには完全に別のインジェクタを作る必要があり、結局テストと本番が異なる環境になってしまった。
  さらにEasyMock vs Mockito論争で、大量のエンジニアリングリソースが無駄になった。
  それ以来、私はmockをほとんど使わない。代わりにシンプルなdummyサービスを作って、最小限の実際の動作をまねるほうがずっと良いと思っている。
  mockに執着する人を見ると、今でも警戒してしまう。

  • 「最小限の正しい動作をするdummy版」なら、それはまさにmockの定義ではないかという疑問がある
  • そうしたdummyをmockとして実装していないなら、mockを誤用しているということだ
  • 私もGoogleで似たような結論に至った。たいていの場合、fakeのほうがmockより良いと思う。ただしGoogleのようにすべてのソースへアクセスできる環境でなければ、mockが必要になる場合もある
  • Mockitoはレガシーコードのリファクタリングや外部ライブラリのテストのような、やむを得ない状況でしか使わなかった。第一選択肢には絶対ならない
  • mockの乱用は「テストピラミッド」の誤解から生まれる。単体テストばかり重視した結果、壊れやすく価値の低いテストが量産される。AIがこうしたテストを自動生成することで、状況はさらに悪化している

• 私はKotlinで4年間Mockitoを使ってきたが、99%のケースでは十分実用的だった。
  複雑だったり混乱したりする場面の大半は、自分の関心の分離不足が原因だった。
  MockKとの差はほとんどなく、単に文法の違い程度だ。ただ、Mockitoのメンテナンスが止まるなら置き換えを検討するかもしれない

  • こういう議論を見ると、むしろプロジェクトがうまくいった証拠のように思える。10年以上尽力した開発者に感謝の乾杯を送りたい
  • 怒りというより、KotlinやRustへ移っていく自然な流れのように見える
  • 最初からKotlin対応は断るべきだったと思う。Kotlin専用フレームワークが別にあったほうが良かっただろう
  • ツール自体の問題ではない。mockやspyが便利すぎて、テスト構造をきちんと設計しなくなることが問題なのだ

• mockは、アプリケーションが4〜5層のときに最も効果を発揮する。
  私も以前はDIを乱用して複雑なコードの網の目を作っていたが、今は層を制限し、一貫した構造を保っている。
  単一クラスのテストにはmockを、要件の検証には統合テストを使う。
  結局重要なのはツールではなく、開発者の規律だ

• MockitoはJavaで最も人気のあるmockingフレームワークだ

  • ただ、これで作られたテスト地獄を経験して、寿命を削られるような気分だった
  • スペイン語では「小さな鼻くそ」という意味なので、名前がちょっと面白い

• プラットフォーム変更により、Mockitoはagentベースになった。JVM 22から動的agentロードがフラグの後ろに隠されたためだ。
  こうした変化はエンタープライズ導入を遅らせる可能性もある

  • 単にテスト実行時にフラグを追加すれば済む程度の話だ
  • どうせ大半の企業はまだJava 8から17へ移行している最中なので、JVM 22の話はかなり先だ

• プラットフォーム変更が、Mockitoコミュニティへの過度な責任転嫁のように感じられた。
  「JVMエコシステムを妨げている」といった非難は健全ではないと思う。

  • とはいえJDKチームはこうした変更を何年も前から予告していた。少し設定を追加すれば依然として動的機能は使えるし、これはプラットフォーム最適化とセキュリティのための正しい選択だ

• オープンソースのメンテナンスは本当に消耗する仕事に見える。
  自分だったら、ただアーカイブして手を引いていただろう。Timが今こそ平穏を取り戻せることを願う

  • それでも品位を保った退場だったと思う。長年注いだ努力を尊重したいし、Timが成し遂げたことは永遠に誇れるものだ

• TimvdLippeに感謝を伝えたい。すばらしいビジョンと献身を示してくれた

• Mockitoは、テストをよく分かっている人が使えば問題ない。
  どんな言語やフレームワークでも、悪いテストは書き手の責任だ

• 「Agent」とは、JVMにアタッチされ、実行中のアプリケーションを計測・変更できるツールを指す。
  プロファイラ、デバッガ、監視ツールなどがこの仕組みを使っている。
  Java 21からはセキュリティ強化のためデフォルトで無効化され、-XX:+EnableDynamicAgentLoading フラグでのみ許可される。
  詳しくは JEP 451文書 を参照。

  • 同じ文書 JEP 451: Prepare to Disallow the Dynamic Loading of Agents に背景説明がある
  • 以前は実行中にデバッガをポート経由で接続できたが、セキュリティ上の問題から、今では起動時に明示的にagentを登録する必要がある