Mockito-Maintainer tritt nach 10 Jahren von seinem Posten zurück

• Ein zentraler Maintainer von Mockito hat angekündigt, seine rund 10-jährige Maintainer-Rolle bis März 2026 zu beenden und in den kommenden Monaten eine schrittweise Übergabe der Zuständigkeiten vorzunehmen
• Als einen direkten Auslöser der Entscheidung nannte er die Änderung der Agent-Richtlinie in JVM 22. Zwar könne er die sicherheitsbedingte Änderung nachvollziehen, doch die einseitige Forderung nach einer Umstellung ohne Alternative und die mangelnde Berücksichtigung auf Ökosystem-Ebene hätten eine große Belastung dargestellt
• Insbesondere erklärte er, dass Mockito zu den größten Nutzern von JVM-Agenten gehört, die Struktur jedoch dazu geführt habe, dass man die Problemlösung ohne Unterstützung durch Build-Tools oder kollaborative Diskussionen schultern musste, was Ressourcenverschleiß und eine Überlastung durch Verantwortung nach sich zog
• Als weiteren Faktor verwies er auf die strukturelle Komplexität der Kotlin-Unterstützung und erklärte, dass Kotlin-spezifische JVM-Verhaltensweisen und nicht dazu passende Funktionen innerhalb von Mockito zu mehr doppelten APIs und verzweigter Logik geführt hätten, was die Wartung erschwere
• Zuletzt teilte er mit, dass er in letzter Zeit bei der Arbeit an der Rust-basierten Web-Engine Servo mehr Freude und Motivation empfinde und angesichts begrenzter persönlicher Zeit zu dem Schluss gekommen sei, dass es schwierig sei, freiwillige Maintainer-Arbeit fortzusetzen, die sich wie eine Pflicht anfühlt

---

Der Meilenstein von 10 Jahren und die Entscheidung zur Übergabe

• Mit März 2026 erreicht er das 10-jährige Jubiläum als Mockito-Maintainer und betrachtet diesen Zeitpunkt als natürlichen Wendepunkt für eine Übergabe der Verantwortung
• In den kommenden Monaten will er sich als bisheriger Maintainer auf Wissensübergabe und die Stabilisierung des Übergangs konzentrieren
• Diskussionen über das künftige Maintainer-Modell und die langfristige Roadmap sollen in einem separaten GitHub-Issue geführt werden

Erschöpfung durch die Änderung der JVM-Agent-Richtlinie

• Hintergrund dafür, dass in Mockito 5 das Standard-Artefakt auf einen JVM-Agenten umgestellt wurde, ist die Richtlinienänderung, nach der das dynamische Anhängen von Agenten ab JVM 22 hinter einem Flag versteckt wurde
• Der sicherheitsbezogenen Stoßrichtung der Änderung stimmt er zu, kritisiert wird jedoch, dass die Entscheidung ohne alternatives Design oder Migrationsunterstützung faktisch vorgegeben wurde
• Obwohl Mockito häufig als führendes Praxisbeispiel für JVM-Funktionen genutzt wurde, habe bei dieser Änderung keine kollaborative Feedback-Schleife funktioniert
• Dass es für Agenten auf Ebene der Build-Tools weiterhin nur unzureichende Unterstützung gibt, wertet er als Zeichen dafür, dass die Priorität dieser Funktion niedrig ist
• Er betont, dass die Open-Source-Kollaborationsstruktur leicht zusammenbrechen kann, wenn freiwillige Maintainer übermäßig unter Druck gesetzt werden

Die strukturelle Last durch Kotlin-Unterstützung

• Die Verbreitung von Kotlin an sich bestreitet er nicht, doch aufgrund der Unterschiede in der internen Funktionsweise der JVM seien in mockito-core zahlreiche Kotlin-spezifische Verarbeitungswege hinzugekommen
• Bei Kotlin-Funktionen wie suspend-Funktionen gebe es Fälle, in denen sie nicht konsistent funktionieren, was zu mehr API-Duplizierung und Komplexität führe
• In der Folge sei die Codebasis spaghettiartig geworden und deutlich schwerer wartbar, und er erwähnte offen, dass ihm diese Arbeit persönlich keinen Spaß mache
• Eine stärker Kotlin-zentrierte Zukunft habe langfristig als Faktor gewirkt, der seine Motivation zur Mockito-Wartung schwächt

Wiedergewonnene Freude durch andere Open-Source-Aktivitäten

• Er hat zu zahlreichen Open-Source-Projekten beigetragen und empfindet in letzter Zeit durch die Arbeit an der Rust-basierten Web-Engine Servo wieder mehr Freude an der Entwicklung
• Bei der Auswahl begrenzter Abendstunden hätten andere Projekte als Mockito dauerhaft größere Zufriedenheit geboten
• Er kam zu dem Schluss, dass ein auf Freiwilligenarbeit basierender Maintainer-Job, der sich über längere Zeit wie eine Pflicht anfühlt, nicht wünschenswert ist

Der Gesamthintergrund der Entscheidung und die Botschaft

• Ernüchterung durch die JVM-Richtlinienänderung, die Grenzen der Struktur für Kotlin-Unterstützung und die wiedergewonnene Motivation in anderen Projekten wirkten als zentrale Faktoren der Entscheidung
• Er räumt ein, dass diese Faktoren nicht auf alle Beitragenden gleichermaßen zutreffen und dass andere die Kotlin-Unterstützung aktiver vorantreiben könnten
• Er entschied sich, die Rolle abzugeben, weil ein Wechsel im Maintainer-Team der langfristigen Gesundheit des Projekts eher zugutekommt
• Die Erfahrung als Open-Source-Maintainer selbst bezeichnete er als Ehre und Privileg und empfahl auch anderen, sich freiwillig zu engagieren

[GN⁺]

Hacker-News-Kommentare

• Bei meinem zweiten Projekt bei Google habe ich Mocking komplett aufgegeben.
  Beim Rewrite eines Systems mit GWT wurde Testabdeckung erzwungen, aber alle testeten nur ihren eigenen Service und injizierten Mocks per DI.
  Das Ergebnis war ein extrem fragiles System, und ein gerade einmal 8 Wochen alter Service fühlte sich bereits wie Legacy-Code an. Schon wenn man nur die Backend-Reihenfolge oder die Zahl der Aufrufe änderte, musste man den ganzen Tag Mocks anpassen.
  Auch die Guice-Modulstruktur war kompliziert, sodass man für die Injection von Mocks in der Testumgebung einen komplett anderen Injector bauen musste; am Ende liefen Tests und Produktion also in unterschiedlichen Umgebungen.
  Außerdem wurden durch Debatten wie EasyMock vs. Mockito massenhaft Engineering-Ressourcen verschwendet.
  Seitdem nutze ich fast nie mehr Mocks. Stattdessen halte ich es für viel besser, einfache Dummy-Services zu bauen, die ein Mindestmaß an realem Verhalten nachbilden.
  Wenn ich Leute sehe, die auf Mocks fixiert sind, werde ich bis heute misstrauisch.

  • Bei einer „Dummy-Version mit minimal korrektem Verhalten“ frage ich mich, ob das nicht genau die Definition eines Mocks ist.
  • Wenn man so einen Dummy nicht als Mock implementiert, verwendet man Mocks falsch.
  • Ich bin bei Google zu einer ähnlichen Schlussfolgerung gekommen. In den meisten Fällen sind Fakes besser als Mocks. Außerhalb einer Umgebung wie Google, in der man Zugriff auf den gesamten Source Code hat, gibt es aber auch Fälle, in denen Mocks nötig sind.
  • Ich habe Mockito nur in unvermeidbaren Situationen eingesetzt, etwa beim Refactoring von Legacy-Code oder beim Testen externer Bibliotheken. Es war nie die erste Wahl.
  • Der Missbrauch von Mocks entsteht aus einem Missverständnis der „Testpyramide“. Weil nur Unit-Tests betont werden, entstehen fragile Tests mit geringem Wert. Da AI solche Tests nun automatisch erzeugt, wird die Lage noch schlimmer.

• Ich habe Mockito in Kotlin 4 Jahre lang verwendet, und in 99 % der Fälle war es völlig brauchbar.
  Komplexe oder verwirrende Situationen lagen meist an meiner unzureichenden Trennung von Zuständigkeiten.
  Zu MockK gibt es kaum Unterschiede, eigentlich nur bei der Syntax. Wenn Mockito aber nicht mehr weiter gepflegt wird, sollte man wohl über einen Wechsel nachdenken.

  • Wenn ich solche Debatten sehe, wirkt das auf mich eher wie ein Beleg dafür, dass das Projekt erfolgreich war. Auf den Entwickler, der sich mehr als 10 Jahre lang engagiert hat, ein Hoch des Dankes.
  • Es wirkt weniger wie Wut als wie ein natürlicher Übergang, ähnlich dem Wechsel zu Kotlin und Rust.
  • Ich denke, man hätte die Kotlin-Unterstützung von Anfang an ablehnen sollen. Ein eigenes Framework nur für Kotlin wäre besser gewesen.
  • Das Problem liegt nicht am Tool selbst. Mocks und Spies sind einfach zu bequem, und genau das führt dazu, dass man die Teststruktur nicht sauber entwirft.

• Mocks sind am effektivsten, wenn eine Anwendung 4 bis 5 Schichten hat.
  Ich selbst habe früher DI überstrapaziert und damit ein komplexes Netz aus Code gebaut, aber heute begrenze ich die Zahl der Schichten und halte die Struktur konsistent.
  Für Tests einzelner Klassen verwende ich Mocks, für die Validierung von Anforderungen Integrationstests.
  Am Ende ist nicht das Tool entscheidend, sondern die Disziplin des Entwicklers.

• Mockito ist das populärste Mocking-Framework in Java.

  • Aber nachdem ich die damit erzeugte Testhölle erlebt habe, hatte ich das Gefühl, sie hätte mir Lebenszeit gekostet.
  • Auf Spanisch bedeutet es wohl „kleiner Popel“, was den Namen etwas komisch macht.

• Durch Plattformänderungen ist Mockito nun agent-basiert, weil dynamisches Laden von Agents ab JVM 22 nur noch hinter einem Flag möglich ist.
  Solche Änderungen könnten die Einführung in Unternehmen verzögern.

  • Man muss beim Ausführen der Tests nur ein zusätzliches Flag setzen.
  • Die meisten Unternehmen sind ohnehin noch damit beschäftigt, von Java 8 auf 17 umzusteigen; JVM 22 ist also noch weit entfernt.

• Die Plattformänderung fühlte sich an, als würde der Mockito-Community übermäßig viel Verantwortung zugeschoben.
  Vorwürfe nach dem Muster „Ihr blockiert das JVM-Ökosystem“ halte ich nicht für gesund.

  • Das JDK-Team hat diese Änderung allerdings schon seit Jahren angekündigt. Mit etwas zusätzlicher Konfiguration kann man dynamische Funktionen weiterhin nutzen, und das ist die richtige Entscheidung für Plattformoptimierung und Sicherheit.

• Die Pflege von Open Source wirkt wirklich auszehrend.
  Ich hätte das Projekt wohl einfach archiviert und mich zurückgezogen. Ich hoffe, Tim findet jetzt wenigstens Ruhe.

  • Trotzdem war es meiner Meinung nach ein Abgang mit Würde. Ich respektiere die Mühe, die über so lange Zeit hineingeflossen ist, und auf das, was Tim erreicht hat, kann er für immer stolz sein.

• Ich möchte TimvdLippe meinen Dank aussprechen. Er hat großartige Vision und Hingabe gezeigt.

• Mockito ist in Ordnung, wenn es von jemandem verwendet wird, der sich mit Tests wirklich auskennt.
  In jeder Sprache und in jedem Framework sind schlechte Tests die Schuld derjenigen, die sie schreiben.

• Ein „Agent“ ist ein Tool, das sich an die JVM anheftet und eine laufende Anwendung instrumentieren oder verändern kann.
  Profiler, Debugger und Monitoring-Tools verwenden diesen Mechanismus.
  Seit Java 21 ist er aus Sicherheitsgründen standardmäßig deaktiviert und nur noch mit dem Flag -XX:+EnableDynamicAgentLoading erlaubt.
  Details stehen im JEP-451-Dokument.

  • Im selben Dokument JEP 451: Prepare to Disallow the Dynamic Loading of Agents wird auch der Hintergrund erklärt.
  • Früher konnte man zur Laufzeit einen Debugger per Port verbinden, aber wegen Sicherheitsproblemen muss man Agents heute beim Start explizit registrieren.