ハクソク

世界を動かす技術を、日本語で。

10年間のMockitoメンテイナーを退任します

109日前原文(github.com)

概要

  • Mockitoのメンテナーを10年務めた節目で、次世代への引き継ぎを決意
  • JVMエージェントの仕様変更による負担増が理由の一つ
  • Kotlin対応の複雑化が今後の課題
  • オープンソース活動の楽しみの変化
  • 今後の引き継ぎ計画や議論は別途GitHubで実施予定

Mockitoメンテナー交代を決意した理由

  • 2026年3月でMockitoメンテナー歴10年の節目
  • 10年という区切りで、他の人へのバトンタッチを決断
  • 引き継ぎに向けて、今後数ヶ月で準備活動を実施予定
  • 今後の運営や議論は、別のGitHub Issueで案内予定

JVMエージェント変更による負担

  • Mockito 5でメインアーティファクトがエージェント化される仕様変更
  • JVM 22からダイナミックアタッチがフラグ付きに変更
  • セキュリティ強化の観点から理解はできるが、メンテナーへの負担増
  • 代替案や十分なサポートがないまま、自主対応を求められる状況
  • オープンソース運営のボランティア性と、個人への過度なプレッシャー
  • XKCDのジョークにもある「数人の個人に依存するOSS世界」の現実

Kotlin対応の難しさ

  • Kotlin人気の高まりとMockitoの複数JVM言語対応
  • 他のJVM言語と異なり、Kotlin固有の実装や分岐が必要
  • mockito-core内でKotlin専用フローやAPIの重複が発生
  • KotlinのJVM上の挙動の一貫性欠如（例：suspend関数）
  • コードの複雑化・メンテナンス性低下
  • Kotlinが主流化する将来に対し、モチベーション維持が困難

他のオープンソース活動への興味

  • オープンソース活動への情熱は継続
  • 最近はRust製WebエンジンServoなど他プロジェクトに魅力を感じる
  • 限られた時間での活動選択で、Mockitoへの優先度が低下
  • 本来ボランティア活動は「やりがい」が前提
  • 義務感での活動継続は長続きしないという気づき

まとめと今後について

  • 上記3点が重なり、メンテナー交代を決断
  • 最初の理由で「立場を見直すきっかけ」、2つ目で「将来への不安」、3つ目で「他の楽しみの発見」
  • 他のメンテナーには異なるモチベーションもあり、プロジェクトの多様性を尊重
  • 10年間でMockitoを前進させたという満足感
  • 今後は新しい世代にバトンタッチし、プロジェクトの発展を期待
  • オープンソース活動の価値を改めて実感し、全ての貢献者に感謝

Hackerたちの意見

僕みたいに知らない人のために言うと、Mockitoは「Java用の最も人気のあるモッキングフレームワーク」だよ。
└
これを使ったテストの混乱に対処するのに、何年も寿命が縮まった気がする。
└
スペイン語では「小さな鼻くそ」って意味にもなるから、あの名前が良いアイデアだと思った人が誰なのかいつも疑問に思ってた。
>Mockito 5では、メインのアーティファクトがエージェントになったという破壊的な変更があったんだ。JVM 22から、以前の「エージェントの動的アタッチ」がフラグの背後に隠されることになったから。これって、Java 8が長い間使われていたのと同じように、企業での採用を妨げるんじゃないかな？
└
JVM 22のことは、企業でメインラインになるまで何年もかかるよ。Java 25がそれを含む最初のLTSリリースだけど、やっとリリースされたばかりだし。ほとんどのところは、8を17に切り替えるのにやっとって感じだね。
└
それは、テストランにフラグを追加する必要があるってことだね。
これはモックをやめて、アダプターを使ったフェイクに切り替える良い機会だね。モックは脆弱なテストを作るだけでなく、フレームワーク自体をテストすることが多いし、しかもそのやり方がすごく遅い。あと、Kotlinの「少し違う構文で車輪を再発明して新しいものと呼ぶ」アプローチもね。さようなら、彼らがmockkとか呼ばれるものを、意味不明な「フルーエント」構文で実装するのを見守るよ。
└
モックやフェイク、その他のものはいつもひどいアイデアだったと思う。人々はその時には気づいていなかったけど、設計が悪いコードをテスト可能にするためのバンドエイドだったんだ。モックを使う必要があるときは、コードの設計に問題があることを示す最も明確な警告サインの一つだよ。時間はかかったけど、業界はようやく（ゆっくりだけど）この認識に至っているみたい。これが進めば、ほとんどの問題が解消されるといいな。
わお、これらの投稿には結構怒りがこもってるね。僕はKotlinで約4年間Mockitoを使ってきたけど、99%のケースでは「十分良い」と感じてた。もっと複雑だったり混乱したりしたのは大体自分のせいだったし（関心の分離が不十分だったり）。spy()とmock()の機能はかなり役立ったと思う。MockKよりも有意義に使えるとは思わなかったけど、MockKが「Kotlinにより適している」と聞いたことはある。僕にとってはほとんど語彙の違いだけだね。Mockitoがメンテされなくなるようなら、MockKに切り替える必要があるかもしれないから、今後の動向を見守っておくよ。
└
結局、ツール自体には何の問題もないと思う。問題は、モックやスパイが関数の効果を適切に隔離するのを簡単にしちゃうことなんだ。そうすると、テストの95%がテストしたい条件を作るための複雑なモックの配列を設定することに費やされて、次に読む人には全く理解できないテストになっちゃうんだよね。
└
「わあ、これらの投稿にはたくさんの怒りがあるね。」もし私がOPだったら、やりがいのない仕事をしっかりやり遂げて、幸せに引退するだろうな！やってることを考えれば、怒りが多い方がいいよ。Mockitoみたいなプロジェクトは、怠け者や無気力な人たちを指摘してるし、その反応を見て笑ってしまうこともできる。彼は10年間、人々を助けるために時間と労力を注いできたんだ。彼自身が言ってる通り、人生のほぼ3分の1を捧げたんだから。私はグラスを上げて「お疲れ様」とか、イギリス人なら「ワッセイル」とか言うよ。
└
それって怒りなのかな？エージェントのことかも。残りの2つのポイントは、要するに1. Kotlinはハックだし、2. Rustの方が楽しいってことみたい。もっと良い環境に移りたいって気持ちも分かるな。
オープンソースの何かを運営するのって、外から見るとすごく大変そうだよね。なんでオーナーやメンテナはこんなに優雅にやってるのか分からない。私だったら、もうやめてリポジトリをアーカイブするか、誰かに引き継ぐかな。ティムが辞めた後、少しは落ち着けるといいね。
Googleでの2つ目のプロジェクトで、モックを使う気が完全になくなったんだ。それ以来、ほとんどやってない。2つのことが起きたんだけど、まず1つ目は、何かの書き直しをしてた時に（GWTを使ってたし、もう10年以上前の話）、テストカバレッジやテスト要件をたくさん持つことになったんだ。まあ、それ自体はいいんだけど、強制的に実施されて、みんな自分のサービスをテストして、モックをDIでたくさん入れてた。結果は完全に予想通りで、システム全体がすごく脆弱になって、8週間しか存在しなかったサービスがレガシーコードみたいに振る舞ってた。バックエンドサービスを切り替えたり、呼び出しの順番を変えたり、特定のサービスを予想以上に呼び出したりするだけで、30分の変更のためにテストのモックを直すのに半日かかることもあった。ほんとにひどかったし、時間の無駄だった。DIの部分もひどくて、全部Guiceを使ってて、モジュールがモジュールをインストールするような感じで、テスト環境でモックを返すように修正するのは大変だった。結局、テストコードと本番コードで異なる環境（とインジェクター）になることが多くて、何をテストしてるのか分からなくなる。2つ目は、その頃、会社のJavaエンジニアたちがEasyMockとMockitoのどちらを使うか決めるために大規模な無駄遣いをしてたんだ。どちらの利点がどうこう言っても、実際にはそれほど違いはないし、既存のコードでモックフレームワークを完全に変更する価値はない。これにどれだけのエンジニアの時間が無駄になったか分からない。モックは悪い習慣を助長して、偽の安心感を与えるだけ。解決策は、最小限の正しい動作を持つダミーのサービスやインターフェースを作ることだよ。たとえば、IDに対する権限やメタデータを簡単に調べるダミーのアイデンティティサービスがあるとする。それがテストのために必要なもので、モックでやるのは本当に間違ってる。以来、モックはほとんど使ってないし、モックやモックフレームワークに強い意見を持ってる人を見ると、すごく警戒するようになった。
└
「解決策は、最小限の正しい動作を持つダミーのサービスやインターフェースを作ることだ」もしモックを使ってこれをやってないなら、モックの使い方を間違ってるよ。
モックは、開発者がアプリケーションを4-5層深く保つと効果的だよ（正直、97%の時間はそれ以上は必要ない：イニシエーター、コントローラー、サービス、トランスポート、クロスカッティングの懸念）。問題は、エンジニアは問題を解決するのが好きで、一番面白い問題は仮想的なものだってこと！そう、私はDIを使ってコードのクモの巣を作ってたことがあった。ツールのせいじゃなくて、自分の態度が問題だったんだ。難しいことに取り組みたかったから、難しいものを作っちゃった。今は、チームと私は4-5層の深さに制限して、コードベースは引き締まってて、一貫性があって、自然に99%近くのテストカバレッジがある。単一のクラスのテストにはモックテストを使って、もちろん要件のテストには統合テストを使ってる。みんながこうするわけじゃないし、それはそれでいいけど、一番大事なのは計画を立てて、それを守ることだと思う。結局、ツールのせいにしないで、自分（や同僚）が単に規律を欠いてるだけなんだから。
| 私の個人的な見解は、変化に関わった人たちがその社会的影響を過小評価していたということです。適切なビルドサポートが今も存在しないという事実は、エージェントが優先事項ではないことを示しています。それが優先事項でないならそれでいいけど、Mockitoとコミュニケーションを取ったとき、私は「Mockitoが動的アタッチを使ってJVMエコシステムを妨げているので、すぐに切り替えて自分で解決してください」と受け取ったんです。この件についてプラットフォームチームの見解を聞きたいです。現状では、エコシステムの中でこんなに重要なライブラリがプラットフォームの変更のスケープゴートにされているのは、かなり悲しい状況です。ライブラリのメンテナコミュニティをこんな風に扱うのは健全ではありません。
TimvdLippe: すごい仕事してるね！アイデアもビジョンも素晴らしい。ありがとうって言いたかっただけ。
素晴らしい降板の投稿だね。これ以上のものは望めないよ。次のプロジェクトを楽しんで！