El mantenedor de Mockito deja su cargo después de 10 años

 (github.com/mockito)
3 puntos por GN⁺ 2025-12-30 | 1 comentarios | Compartir por WhatsApp
  • El mantenedor principal de Mockito anunció que para marzo de 2026 cerrará una etapa de लगभग 10 años en ese rol y que durante los próximos meses llevará adelante una transferencia gradual de responsabilidades
  • Como uno de los detonantes directos de la decisión, mencionó el cambio de política sobre agentes en la JVM 22; aunque coincide con el objetivo de seguridad del cambio, señaló que la exigencia de una transición unilateral sin alternativas y la falta de consideración a nivel del ecosistema representaron una carga importante
  • En particular, explicó que aunque Mockito es uno de los mayores usuarios de agentes de la JVM, terminó asumiendo la resolución del problema sin soporte de herramientas de build ni discusiones colaborativas, lo que derivó en desgaste de recursos y exceso de responsabilidad
  • También señaló como otro factor la complejidad estructural del soporte para Kotlin, indicando que funciones desalineadas con la forma en que Kotlin opera sobre la JVM han aumentado las API duplicadas y la lógica condicional dentro de Mockito, dificultando el mantenimiento
  • En tiempos recientes, comentó que siente más disfrute y motivación trabajando en Servo, el motor web basado en Rust, y que, considerando su tiempo personal limitado, llegó a la conclusión de que le resulta difícil seguir con una tarea voluntaria de mantenimiento que ya se siente como una obligación

El hito de los 10 años y la decisión de transferir el rol

  • En marzo de 2026 se cumplirán 10 años desde que asumió el mantenimiento de Mockito, y considera ese momento como un punto natural para el traspaso de responsabilidades
  • Durante los próximos meses planea enfocarse, como mantenedor actual, en transferir conocimiento y estabilizar la transición
  • Las conversaciones sobre el próximo esquema de mantenimiento y la hoja de ruta a largo plazo se llevarán a cabo en un issue separado de GitHub

Desgaste por el cambio de política de agentes en la JVM

  • El contexto de que en Mockito 5 el artefacto predeterminado pasara a ser un agente de la JVM está relacionado con el cambio de política en la JVM 22, donde el adjuntado dinámico de agentes quedó oculto detrás de una bandera
  • Aunque está de acuerdo con la intención del cambio desde la perspectiva de seguridad, criticó que la decisión se diera por hecha sin un diseño alternativo ni apoyo para la migración
  • Aun cuando Mockito se había usado frecuentemente como caso de referencia para funcionalidades de la JVM, en este cambio no funcionó un ciclo de retroalimentación colaborativo
  • Evaluó que la falta persistente de soporte a nivel de herramientas de build para agentes muestra que la prioridad de esta funcionalidad sigue siendo baja
  • Subrayó que, si se ejerce una presión excesiva sobre mantenedores que contribuyen voluntariamente, la estructura de colaboración del código abierto puede colapsar con facilidad

La carga estructural causada por el soporte para Kotlin

  • No cuestiona la expansión de Kotlin en sí, pero debido a las diferencias en el funcionamiento interno sobre la JVM, se han agregado a mockito-core muchos flujos de manejo específicos para Kotlin
  • Existen casos en los que funciones de Kotlin, como las funciones suspend, no operan de manera consistente, lo que incrementa la duplicación de API y la complejidad
  • Como resultado, la base de código se ha vuelto más enredada y más difícil de mantener, y comentó con franqueza que ese trabajo no le resulta disfrutable a nivel personal
  • Un futuro más centrado en Kotlin también ha debilitado su motivación para seguir manteniendo Mockito a largo plazo

Recuperar el disfrute en otras actividades de código abierto

  • Ha contribuido a múltiples proyectos de código abierto y, recientemente, volvió a sentir la alegría de desarrollar trabajando en Servo, el motor web basado en Rust
  • Entre las opciones para su tiempo libre por las noches, otros proyectos le están dando más satisfacción que Mockito de forma sostenida
  • Considera que no es deseable que una tarea de mantenimiento voluntaria se sienta como una obligación durante tanto tiempo

Contexto general de la decisión y mensaje final

  • El desencanto por los cambios de política en la JVM, los límites estructurales del soporte para Kotlin y la recuperación de motivación en otros proyectos fueron los factores clave de la decisión
  • Reconoció que estos factores no se aplican de la misma manera a todos los contribuidores y que otras personas podrían estar más dispuestas a impulsar el soporte para Kotlin
  • Decidió dejar el rol al considerar que un relevo en el mantenimiento será más beneficioso para la salud a largo plazo del proyecto
  • Evaluó la experiencia misma de mantener un proyecto de código abierto como un honor y un privilegio, y animó a otras personas a participar también con contribuciones voluntarias

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-12-30
Comentarios en Hacker News

  • Mientras trabajaba en mi segundo proyecto en Google, terminé abandonando por completo el mocking
    Durante una reescritura del sistema con GWT se exigía cobertura de pruebas, pero cada quien probaba solo su propio servicio e inyectaba mocks con DI
    Como resultado, el sistema se volvió extremadamente frágil, y un servicio de apenas 8 semanas ya se sentía como código legado
    Si cambiabas el orden del backend o la cantidad de llamadas, podías pasarte todo el día ajustando mocks
    La estructura de módulos de Guice también era compleja, así que para inyectar mocks en el entorno de pruebas había que crear un inyector completamente distinto, y al final testing y producción terminaron siendo entornos diferentes
    Además, se desperdiciaron muchísimos recursos de ingeniería en discusiones de EasyMock vs Mockito
    Desde entonces casi no uso mocks. En su lugar, me parece mucho mejor crear servicios dummy simples que imiten el comportamiento real mínimo
    Todavía hoy me pongo en alerta cuando veo gente obsesionada con los mocks

    • Me hace preguntarme si una “versión dummy con el comportamiento mínimo correcto” no es precisamente la definición de un mock
    • Si no implementas ese dummy como mock, entonces estás usando mal los mocks
    • Yo también llegué a una conclusión parecida en Google. En la mayoría de los casos, creo que un fake es mejor que un mock. Eso sí, fuera de un entorno como Google donde tienes acceso a todo el código fuente, hay casos en los que sí hacen falta mocks
    • Solo usé Mockito en situaciones inevitables, como refactorización de código legado o pruebas de librerías externas. Nunca como primera opción
    • El abuso de mocks viene de una mala interpretación de la “pirámide de pruebas”. Por enfatizar solo las pruebas unitarias, se termina produciendo pruebas frágiles y de poco valor. La IA está empeorando la situación al generar estas pruebas de forma automática

  • He usado Mockito durante 4 años en Kotlin, y en el 99% de los casos me pareció suficientemente útil
    Las situaciones complejas o confusas casi siempre se debían a mi falta de separación de responsabilidades
    Casi no hay diferencia con MockK, salvo por la sintaxis. Eso sí, si Mockito deja de mantenerse, probablemente habría que pensar en reemplazarlo

    • Cuando veo este tipo de discusiones, más bien me parece una señal de que el proyecto salió bien. Brindo en agradecimiento por un desarrollador que se entregó por más de 10 años
    • Más que enojo, parece un flujo natural hacia Kotlin y Rust
    • Creo que desde el inicio debieron haber rechazado el soporte para Kotlin. Habría sido mejor que existiera un framework exclusivo para Kotlin
    • No es problema de la herramienta en sí. El problema es que los mocks y spies son tan cómodos que uno deja de diseñar bien la estructura de las pruebas

  • Los mocks son más efectivos cuando una aplicación tiene 4 o 5 capas
    Yo también antes abusaba de DI y creaba una red de código compleja, pero ahora limito las capas y mantengo una estructura consistente
    Uso mocks para probar clases individuales, y pruebas de integración para validar requisitos
    Al final, lo importante no es la herramienta sino la disciplina del desarrollador

  • Mockito es el framework de mocking más popular en Java

    • Pero después de pasar por el infierno de pruebas creado con esto, sentí que me acortó la vida
    • En español significa “moco chiquito”, así que el nombre da un poco de risa

  • Por un cambio de plataforma, Mockito pasó a estar basado en agents, porque desde JVM 22 la carga dinámica de agents quedó escondida detrás de una bandera
    Este tipo de cambios podría retrasar su adopción en entornos empresariales

    • Es solo cosa de agregar una bandera al ejecutar las pruebas
    • De todos modos, la mayoría de las empresas apenas sigue migrando de Java 8 a 17, así que JVM 22 todavía está muy lejos

  • El cambio de plataforma se sintió como una transferencia excesiva de responsabilidad hacia la comunidad de Mockito
    No me parece sano culparlos diciendo que “están frenando el ecosistema JVM”

    • Pero el equipo del JDK lleva años avisando sobre este cambio. Sigue siendo posible usar funciones dinámicas con un poco de configuración, y es una decisión correcta por optimización de plataforma y seguridad

  • Mantener software de código abierto realmente parece un trabajo agotador
    Si fuera yo, simplemente lo archivaría y me retiraría. Ojalá Tim encuentre algo de paz ahora

    • Aun así, me pareció una salida con dignidad. Respeto el esfuerzo que entregó durante tanto tiempo, y Tim siempre podrá sentirse orgulloso de lo que logró

  • Quiero dejarle unas palabras de agradecimiento a TimvdLippe. Mostró una gran visión y dedicación

  • Mockito está bien si lo usa alguien que realmente sabe de testing
    En cualquier lenguaje o framework, las malas pruebas son culpa de quien las escribe

  • Un “Agent” es una herramienta que se adjunta a la JVM y puede instrumentar o modificar una aplicación mientras está en ejecución
    Profilers, depuradores y herramientas de monitoreo usan este mecanismo
    Desde Java 21 viene desactivado por defecto por razones de seguridad, y solo se permite con la bandera -XX:+EnableDynamicAgentLoading
    Para más detalles, consulta el documento JEP 451