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

2025年12月29日原文(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の方が楽しいってことみたい。もっと良い環境に移りたいって気持ちも分かるな。

Hacker Newsで議論の続きを見る

ハクソク