Le mainteneur principal de Mockito quitte ses fonctions après 10 ans

• Le mainteneur principal de Mockito a annoncé qu’il mettrait fin à près de 10 ans de travail de maintenance en mars 2026, avec un transfert progressif des responsabilités prévu dans les prochains mois
• Comme l’un des déclencheurs directs de cette décision, il cite le changement de politique concernant les agents sur JVM 22 : il comprend l’objectif de sécurité de cette évolution, mais estime que l’exigence d’une transition unilatérale sans alternative et le manque de prise en compte de l’écosystème ont représenté une lourde charge
• Il explique notamment que, bien que Mockito soit l’un des plus gros utilisateurs d’agents JVM, l’absence de support des outils de build ou de discussions collaboratives l’a conduit à assumer seul la résolution du problème, ce qui a entraîné épuisement des ressources et surcharge de responsabilité
• Il souligne aussi comme autre facteur la complexité structurelle du support de Kotlin, en expliquant que certaines fonctionnalités incompatibles avec le mode de fonctionnement propre de Kotlin sur la JVM ont entraîné dans Mockito une augmentation des API dupliquées et de la logique conditionnelle, rendant la maintenance plus difficile
• Ces derniers temps, il dit trouver davantage de plaisir et de motivation dans son travail sur Servo, le moteur web en Rust, et, compte tenu de son temps personnel limité, il est arrivé à la conclusion qu’il lui est difficile de poursuivre un travail de maintenance bénévole qui ressemble à une obligation

---

Un cap de 10 ans et la décision de transmettre le rôle

• En mars 2026, il atteindra le 10e anniversaire de sa maintenance de Mockito, et considère cette échéance comme un point de bascule naturel pour transmettre la responsabilité
• Au cours des prochains mois, il prévoit de se concentrer sur le transfert des connaissances et la stabilisation de la transition en tant que mainteneur actuel
• Les discussions sur la future organisation de la maintenance et la feuille de route à long terme auront lieu dans une issue GitHub distincte

L’épuisement causé par le changement de politique sur les agents JVM

• Si, dans Mockito 5, l’artefact par défaut a été converti en agent JVM, c’est dans le contexte du changement de politique de la JVM 22 qui a relégué l’attachement dynamique d’agents derrière un flag
• Il se dit d’accord avec l’intention de sécurité de ce changement, mais critique le fait que la décision ait été imposée sans conception alternative ni aide à la migration
• Bien que Mockito ait souvent servi d’exemple pionnier pour les fonctionnalités de la JVM, aucune boucle de retour collaborative n’a véritablement fonctionné lors de ce changement
• Il estime que le manque persistant de support au niveau des outils de build pour les agents montre que cette fonctionnalité reste une faible priorité
• Il souligne que si une pression excessive est exercée sur des mainteneurs bénévoles, la structure de collaboration open source peut facilement se briser

Le poids structurel provoqué par le support de Kotlin

• Il ne remet pas en cause l’essor de Kotlin, mais explique qu’en raison des différences de fonctionnement internes sur la JVM, de nombreux flux de traitement spécifiques à Kotlin ont été ajoutés à mockito-core
• Certaines fonctionnalités de Kotlin, comme les fonctions suspend, ne fonctionnent pas de manière cohérente, ce qui accroît la duplication d’API et la complexité
• En conséquence, la base de code s’est transformée en spaghetti et la difficulté de maintenance a augmenté, et il reconnaît franchement que ce travail n’est pas agréable pour lui
• Un avenir davantage centré sur Kotlin a aussi contribué à affaiblir sa motivation à long terme pour maintenir Mockito

Retrouver du plaisir dans d’autres activités open source

• Il a contribué à de nombreux projets open source et, récemment, il retrouve le plaisir du développement grâce à son travail sur Servo, le moteur web en Rust
• Dans le choix limité de ses soirées, d’autres projets lui apportent davantage de satisfaction que Mockito de façon continue
• Il considère qu’un travail de maintenance bénévole qui finit par ressembler à une obligation sur le long terme n’est pas souhaitable

Contexte global de la décision et message transmis

• Le sentiment de lassitude causé par les changements de politique de la JVM, les limites structurelles du support de Kotlin et le regain de motivation dans d’autres projets ont constitué les facteurs clés de sa décision
• Il reconnaît que ces facteurs ne s’appliquent pas de la même manière à tous les contributeurs et que d’autres peuvent être plus enclins à investir dans le support de Kotlin
• Il a décidé de quitter son rôle en estimant qu’un changement de mainteneur serait plus bénéfique pour la santé à long terme du projet
• Il décrit son expérience de la maintenance open source comme un honneur et un privilège, et encourage aussi les autres à contribuer bénévolement

[GN⁺]

Réactions sur Hacker News

• En travaillant sur un deuxième projet chez Google, j’ai fini par abandonner complètement le mocking
  Lors d’une réécriture du système avec GWT, la couverture de test était imposée, mais chacun ne testait que son propre service et injectait des mocks via la DI
  Résultat, le système est devenu extrêmement fragile, au point qu’un service vieux de 8 semaines donnait déjà l’impression d’être du code legacy
  Il suffisait de changer l’ordre du backend ou le nombre d’appels pour passer la journée entière à corriger les mocks
  La structure des modules Guice était aussi tellement complexe que, pour injecter des mocks destinés à l’environnement de test, il fallait créer un injector totalement différent, si bien que les tests et la production finissaient par tourner dans des environnements distincts
  Sans parler de l’énorme gaspillage de ressources d’ingénierie dans les débats EasyMock vs Mockito
  Depuis, je n’utilise presque plus de mocks. À la place, je pense qu’il vaut bien mieux créer un service dummy simple qui imite un minimum de comportement réel
  Aujourd’hui encore, je me méfie des gens obsédés par les mocks

  • Je me demande si une “version dummy avec un comportement minimalement correct” n’est pas justement la définition d’un mock
  • Si ce dummy n’est pas implémenté comme un mock, alors c’est qu’on utilise mal les mocks
  • Je suis arrivé à une conclusion similaire chez Google. Dans la plupart des cas, un fake est meilleur qu’un mock. Cela dit, en dehors d’un environnement comme Google où tout le code source est accessible, il y a des cas où les mocks restent nécessaires
  • Je n’utilisais Mockito que dans des situations inévitables, comme le refactoring de code legacy ou les tests de bibliothèques externes. Ce n’était jamais mon premier choix
  • L’abus de mocks vient d’une mauvaise compréhension de la “pyramide des tests”. À force de ne valoriser que les tests unitaires, on produit en masse des tests fragiles et peu utiles. Et l’IA aggrave encore la situation en générant automatiquement ce genre de tests

• J’utilise Mockito en Kotlin depuis 4 ans, et dans 99 % des cas cela m’a semblé tout à fait satisfaisant
  Les situations complexes ou déroutantes venaient le plus souvent de mon manque de séparation des responsabilités
  Il n’y a presque pas de différence avec MockK, c’est surtout une question de syntaxe. En revanche, si la maintenance de Mockito s’arrête, il faudra peut-être envisager un remplacement

  • Quand je vois ce genre de débat, j’y vois plutôt la preuve que le projet a bien réussi. Un toast de remerciement à un développeur qui s’y est consacré pendant plus de 10 ans
  • Plus qu’une colère, cela ressemble à une évolution naturelle, comme le passage vers Kotlin et Rust
  • Je pense qu’il aurait fallu refuser dès le départ le support de Kotlin. Il aurait mieux valu avoir un framework dédié à Kotlin
  • Le problème ne vient pas de l’outil lui-même. Le vrai problème, c’est que les mock et spy sont tellement pratiques qu’on finit par ne plus concevoir correctement la structure des tests

• Les mocks sont surtout efficaces quand une application a 4 à 5 couches
  Moi aussi, autrefois, j’abusais de la DI au point de créer un enchevêtrement de code complexe, mais aujourd’hui je limite les couches et je garde une structure cohérente
  J’utilise des mocks pour tester une classe isolée, et des tests d’intégration pour valider les exigences
  Au final, ce qui compte, ce n’est pas l’outil mais la discipline du développeur

• Mockito est le framework de mocking le plus populaire en Java

  • Mais après avoir traversé l’enfer des tests construits avec ça, j’avais l’impression d’y laisser des années de vie
  • En espagnol, cela veut dire “petite crotte de nez”, donc le nom est assez drôle

• Avec les changements de plateforme, Mockito est passé à une approche basée sur des agents, car à partir de la JVM 22, le chargement dynamique d’agents a été masqué derrière un flag
  Ce type de changement pourrait ralentir son adoption en entreprise

  • En pratique, il suffit juste d’ajouter un flag au moment d’exécuter les tests
  • De toute façon, la plupart des entreprises sont encore en train de migrer de Java 8 vers 17, donc la JVM 22, c’est une histoire pour bien plus tard

• J’ai eu l’impression que les changements de plateforme faisaient peser une responsabilité excessive sur la communauté Mockito
  Je ne trouve pas sain de lui reprocher de “bloquer l’écosystème JVM”

  • Pourtant, l’équipe du JDK annonçait ce changement depuis des années. Il suffit d’ajouter un peu de configuration pour continuer à utiliser ces fonctions dynamiques, et c’est le bon choix pour l’optimisation de la plateforme et la sécurité

• La maintenance open source donne vraiment l’impression d’être un travail épuisant
  À sa place, j’aurais simplement archivé le projet et passé à autre chose. J’espère que Tim trouvera enfin la paix

  • Malgré tout, je pense que c’était une sortie digne. Je respecte les efforts fournis pendant si longtemps, et Tim pourra être fier à jamais de ce qu’il a accompli

• J’aimerais adresser mes remerciements à TimvdLippe. Il a fait preuve d’une vision et d’un engagement remarquables

• Mockito convient très bien quand il est utilisé par quelqu’un qui maîtrise vraiment les tests
  Dans n’importe quel langage ou framework, les mauvais tests sont la faute de leur auteur

• Un “Agent” désigne un outil qui s’attache à la JVM pour instrumenter ou modifier une application en cours d’exécution
  Les profileurs, débogueurs et outils de monitoring utilisent ce mécanisme
  Depuis Java 21, il est désactivé par défaut pour des raisons de sécurité, et n’est autorisé qu’avec le flag -XX:+EnableDynamicAgentLoading
  Voir la documentation JEP 451 pour plus de détails

  • Le même document, JEP 451: Prepare to Disallow the Dynamic Loading of Agents, donne aussi des explications de contexte
  • Autrefois, on pouvait connecter un débogueur à un port pendant l’exécution, mais pour des raisons de sécurité, il faut désormais enregistrer explicitement l’agent au démarrage