Mantenedor do Mockito deixa o cargo após 10 anos

 (github.com/mockito)
3 pontos por GN⁺ 2025-12-30 | 1 comentários | Compartilhar no WhatsApp
  • O mantenedor principal do Mockito anunciou que, em março de 2026, encerrará cerca de 10 anos no papel de manutenção e que, nos próximos meses, fará uma transferência gradual de responsabilidades
  • Como um dos gatilhos diretos da decisão, ele citou a mudança de política de agentes na JVM 22; embora concorde com a mudança em si por motivos de segurança, afirmou que a exigência de uma transição unilateral sem alternativa e a falta de consideração pelo ecossistema pesaram bastante
  • Em especial, explicou que, mesmo com o Mockito sendo um dos maiores usuários de agentes da JVM, a estrutura em que teve de assumir a solução do problema sem suporte das ferramentas de build nem discussões colaborativas levou a esgotamento de recursos e excesso de responsabilidade
  • Como outro fator, apontou a complexidade estrutural do suporte a Kotlin, observando que recursos desalinhados com a forma como o Kotlin opera na JVM aumentaram dentro do Mockito as APIs duplicadas e a lógica condicional, dificultando a manutenção
  • Recentemente, ele vem encontrando mais prazer e motivação no trabalho com o Servo, motor web baseado em Rust, e compartilhou que, considerando o tempo pessoal limitado, chegou à conclusão de que é difícil continuar um trabalho voluntário de manutenção que passou a parecer uma obrigação

O marco de 10 anos e a decisão de transferir o papel

  • Em março de 2026, ele completará 10 anos na manutenção do Mockito e vê esse momento como um ponto natural de inflexão para transferir a responsabilidade
  • Nos próximos meses, pretende se concentrar, como mantenedor atual, na transferência de conhecimento e estabilização da transição
  • As discussões sobre o próximo modelo de manutenção e o roadmap de longo prazo devem ocorrer em uma issue separada no GitHub

Esgotamento causado pela mudança na política de agentes da JVM

  • O contexto para que, no Mockito 5, o artefato padrão fosse convertido para um agente da JVM está na mudança de política a partir da JVM 22, em que o anexo dinâmico de agentes passou a ficar escondido atrás de uma flag
  • Embora concorde com a intenção da mudança do ponto de vista de segurança, ele aponta como problema o fato de a decisão ter sido tomada como dada, sem um design alternativo nem suporte à migração
  • Mesmo com o Mockito tendo sido frequentemente usado como caso de ponta para recursos da JVM, nesta mudança não houve um ciclo colaborativo de feedback funcionando
  • Ele avalia que a falta persistente de suporte a agentes no nível das ferramentas de build mostra que a prioridade desse recurso continua baixa
  • Destaca que, quando se impõe pressão excessiva a mantenedores contribuindo de forma voluntária, a estrutura de colaboração em open source pode ruir facilmente

O peso estrutural causado pelo suporte a Kotlin

  • Ele não nega a expansão do Kotlin, mas afirma que, por causa das diferenças no funcionamento interno da JVM, vários fluxos de tratamento específicos para Kotlin foram adicionados ao mockito-core
  • Há casos em que recursos do Kotlin, como funções suspend, não funcionam de forma consistente, aumentando a duplicação de API e a complexidade
  • Como resultado, a base de código ficou mais embolada e mais difícil de manter, e ele menciona com franqueza que esse trabalho não é pessoalmente prazeroso
  • O futuro cada vez mais centrado em Kotlin acabou enfraquecendo sua motivação de longo prazo para manter o Mockito

Recuperando a satisfação em outras atividades open source

  • Ele contribuiu para vários projetos open source e, recentemente, voltou a sentir prazer no desenvolvimento por meio do trabalho com o Servo, motor web baseado em Rust
  • Entre as opções limitadas para o tempo das noites, outros projetos passaram a oferecer mais satisfação do que o Mockito
  • Concluiu que não é desejável que um trabalho de manutenção voluntário permaneça por muito tempo em um estado que pareça uma obrigação

Contexto geral da decisão e a mensagem deixada

  • A frustração com a mudança de política da JVM, os limites estruturais do suporte a Kotlin e a recuperação da motivação em outros projetos atuaram como os principais fatores da decisão
  • Ele reconhece que esses fatores não se aplicam igualmente a todos os contribuidores e que outras pessoas podem ser mais proativas no suporte a Kotlin
  • Decidiu deixar o papel por considerar que a troca de mantenedor é mais benéfica para a saúde de longo prazo do projeto
  • Avalia a experiência de manutenção em open source como uma honra e um privilégio e recomenda a outras pessoas que também contribuam voluntariamente

Leituras relacionadas

1 comentários

 
GN⁺ 2025-12-30
Comentários do Hacker News

  • No meu segundo projeto no Google, acabei abandonando completamente o mocking
    Ao reescrever o sistema com GWT, a cobertura de testes era obrigatória, mas cada um testava só o próprio serviço e injetava mocks via DI
    Como resultado, o sistema ficou extremamente frágil, e um serviço com 8 semanas já parecia código legado. Bastava mudar a ordem do backend ou a quantidade de chamadas para passar o dia inteiro ajustando mocks
    A estrutura dos módulos do Guice também era complexa, então para injetar mocks para o ambiente de teste era preciso criar um injector totalmente diferente, e no fim teste e produção viraram ambientes distintos
    Além disso, muito recurso de engenharia foi desperdiçado em discussões EasyMock vs Mockito
    Desde então, quase não uso mocks. Em vez disso, acho muito melhor criar serviços dummy simples que imitem o mínimo de comportamento real
    Até hoje fico desconfiado quando vejo gente obcecada por mocks

    • Se estamos falando de uma “versão dummy com o mínimo de comportamento correto”, isso não é justamente a definição de mock?
    • Se você não implementa esse dummy como mock, então está usando mocks de forma errada
    • Também cheguei a uma conclusão parecida no Google. Na maioria dos casos, acho que fakes são melhores que mocks. Mas, fora de um ambiente como o Google, onde se tem acesso a todo o código-fonte, há casos em que mocks são necessários
    • Eu só usava Mockito em situações inevitáveis, como refatoração de código legado ou testes de bibliotecas externas. Nunca como primeira escolha
    • O abuso de mocks vem de um mal-entendido da “pirâmide de testes”. Como só se enfatizam testes unitários, acabam sendo produzidos testes frágeis e de pouco valor. A IA está piorando ainda mais a situação ao gerar esses testes automaticamente

  • Usei Mockito por 4 anos em Kotlin e, em 99% dos casos, ele foi bom o suficiente
    Situações complexas ou confusas quase sempre vinham da minha falta de separação de responsabilidades
    Quase não há diferença para o MockK, é mais uma diferença de sintaxe. Mas, se o Mockito deixar de ser mantido, talvez valha considerar uma troca

    • Quando vejo esse tipo de discussão, penso até que é sinal de que o projeto deu certo. Um brinde de agradecimento ao desenvolvedor que se dedicou por mais de 10 anos
    • Parece menos raiva e mais um movimento natural, como a migração para Kotlin e Rust
    • Acho que deveriam ter recusado suporte a Kotlin desde o começo. Teria sido melhor se existisse um framework dedicado só para Kotlin
    • O problema não é a ferramenta em si. O problema é que mock e spy são convenientes demais, então as pessoas deixam de projetar direito a estrutura dos testes

  • Mocks são mais eficazes quando a aplicação tem 4 ou 5 camadas
    Eu também já abusei de DI e criei uma teia complexa de código, mas hoje limito as camadas e mantenho uma estrutura consistente
    Uso mocks para testes de classe isolada, e testes de integração para validar requisitos
    No fim, o importante não é a ferramenta, e sim a disciplina do desenvolvedor

  • Mockito é o framework de mocking mais popular em Java

    • Mas, depois de passar pelo inferno de testes criado com isso, senti como se estivesse perdendo tempo de vida
    • Em espanhol, significa “melequinha”, então o nome é meio engraçado

  • Com a mudança na plataforma, o Mockito passou a ser baseado em agent, porque a partir da JVM 22 o carregamento dinâmico de agents ficou escondido atrás de uma flag
    Esse tipo de mudança pode atrasar a adoção em ambientes corporativos

    • Na prática, basta adicionar uma flag ao rodar os testes
    • De qualquer forma, a maioria das empresas ainda está migrando do Java 8 para o 17, então JVM 22 ainda é assunto para bem depois

  • Essa mudança de plataforma pareceu uma transferência excessiva de responsabilidade para a comunidade do Mockito
    Acho pouco saudável culpar o projeto como se ele estivesse “bloqueando o ecossistema JVM”

    • Mas a equipe do JDK já vinha avisando sobre essa mudança havia anos. Ainda é possível usar recursos dinâmicos com um pouco de configuração extra, e isso é a escolha certa em nome de otimização da plataforma e segurança

  • Manter software open source parece mesmo um trabalho desgastante
    Se fosse eu, teria simplesmente arquivado tudo e saído fora. Espero que Tim finalmente encontre paz

    • Ainda assim, acho que foi uma saída com dignidade. Respeito o esforço dedicado por tanto tempo, e Tim pode se orgulhar para sempre do que conquistou

  • Quero deixar meu agradecimento a TimvdLippe. Ele mostrou uma visão excelente e muita dedicação

  • Mockito é ok quando usado por quem realmente entende de testes
    Em qualquer linguagem ou framework, testes ruins são culpa de quem os escreve

  • “Agent” é uma ferramenta que se acopla à JVM e pode instrumentar e modificar uma aplicação em execução
    Profilers, depuradores e ferramentas de monitoramento usam esse mecanismo
    Desde o Java 21, isso vem desativado por padrão por motivos de segurança, e só é permitido com a flag -XX:+EnableDynamicAgentLoading
    Para mais detalhes, veja o JEP 451