Stepping down as Mockito maintainer after ten years

Original Article ↗ Hacker News Discussion ↗

Mockito and mocking in practice

  • Many commenters report very painful experiences with Mockito-heavy test suites: huge, brittle tests that shatter on small refactors and make legacy systems feel “untouchable.”
  • Others defend Mockito as a solid tool whose main problem is misuse: trying to unit-test what should be integration-tested, or asserting on internal implementation details instead of behavior.
  • A recurring theme: mocking often enables or hides poor design rather than forcing better decomposition and testability.

Mocks vs fakes, adapters, and integration tests

  • Strong current arguing that heavy mocking is a “code smell”; prefer:
    • Integration tests hitting real DBs/files where practical.
    • Fakes/in‑memory implementations or adapters for external services.
  • Mocks are criticized for:
    • Coupling tests to call order and specific methods.
    • Creating brittle tests that break on harmless refactors (e.g., changing which method is used or adding a preliminary check).
  • Counterpoint: mocks (or other test doubles) are useful/necessary for:
    • Third‑party APIs you can’t run locally.
    • Simulating failures, bad data, and rare edge cases.
    • Keeping large test suites fast and isolated.
  • Distinction raised between:
    • “Mocks” that just verify calls (fragile).
    • “Fakes” that behave like minimal real services (more robust).

Why Java needs mocking libraries

  • Java’s legacy, non‑DI codebases and final classes from third‑party libs make simple interface-based polymorphism insufficient.
  • Mockito reduces boilerplate versus hand-written test doubles, especially for huge interfaces like ResultSet.
  • Some dislike the alternative of proliferating interfaces/adapters just for testing.

JVM agent change and integrity debate (JEP 451)

  • Maintainer cites energy drain from JVM’s move to restrict dynamic agent loading; perceives Mockito as being blamed for “holding the JVM back.”
  • Some ask why not “just set the flag for tests”; others note build tools don’t yet ergonomically support this and burden falls on every user.
  • JVM maintainers in the thread explain the broader “Integrity by Default” goal: limiting arbitrary runtime modification to improve security, performance, and evolvability, while allowing explicit opt‑in via flags/agents.
  • Tension highlighted between platform-level integrity and the costs imposed on widely used tooling like Mockito.

Kotlin and ecosystem friction

  • Maintainer also cites Kotlin’s underlying implementation as painful for a Java-focused mocking framework.
  • Several say Kotlin-specific tools (e.g., MockK) are a better fit, especially in mixed Java/Kotlin codebases.
  • Broader discussion touches on Java’s slower evolution vs. Kotlin’s feature set, with differing views on whether Kotlin is a “hack” or a thoughtfully designed successor.

Open‑source maintenance and burnout

  • Many express sympathy: a decade of unpaid/underpaid work on a critical dependency, then extra work imposed by external platform decisions, is seen as a classic burnout path.
  • Debate over whether money would prevent burnout: some say lack of compensation makes such work intolerable; others argue intrinsic motivation is the only sustainable driver.
  • Broader point: GitHub-era expectations turned permissive sharing into de facto unpaid support, and maintainers need clearer boundaries.

Other minor threads

  • Lighthearted discussion of the “Mockito” name sounding like “small booger” in Spanish.
  • Warnings about potential future supply-chain risk if a critical but possibly under-maintained library is widely depended on.