PHPUnit 13.2: O Avanço em Direção a Testes Mais Estritos e Explícitos

Apresentadora: E aí, pessoal, bem-vindos de volta ao Allur! Eu sou a Juliana Santos e hoje o nosso papo é para quem vive e respira o ecossistema PHP. Olha, se você é daquelas pessoas que acham que teste automatizado é só para ganhar um "visto verde" no terminal e seguir a vida, o episódio de hoje vai te dar um choque de realidade — de um jeito muito bom, eu prometo. A gente vai mergulhar nas novidades do PHPUnit 13.2, que acabou de sair agora em junho de 2026. E olha, não é só uma atualizaçãozinha de rotina, não. A gente está falando de uma mudança de paradigma total. O PHPUnit está ficando mais "bravo", digamos assim, mais estrito, exigindo que a gente seja muito mais explícito no que está testando. Por que o matcher `any()` está morrendo? Por que a gente precisa finalmente entender a diferença entre Mock e Stub? E como o PHP 8.4 está permitindo que nossas suítes de teste voem baixo no CI? É sobre isso que vamos falar hoje. Fica com a gente que o Allur está começando! Apresentadora: E para destrinchar essa versão 13.2 comigo, eu trouxe um cara que manja tudo de arquitetura e testes. Ele é Senior Software Engineer, entusiasta de longa data da comunidade PHP e já quebrou muito a cabeça (e consertou muita coisa) com TDD. Seja muito bem-vindo ao Allur, Ricardo Souza! Massa demais ter você aqui, Ricardo. Convidado: Valeu, Juliana! O prazer é todo meu. Cara, que momento legal pra gente falar de PHP, né? Eu confesso que quando li o changelog da 13.2, eu dei um sorriso e, ao mesmo tempo, pensei: "Vixi, a galera vai ter que trabalhar no refactoring". Mas é pro bem do código, com certeza. Apresentadora: Pois é, Ricardo! O pessoal costuma dizer que o PHPUnit está ficando "chato", mas eu prefiro dizer que ele está ficando profissional. Essa versão 13.2 parece que veio pra acabar com aquela "preguiça" na hora de escrever testes, né? Começando pelo fato de que ela agora exige o PHP 8.4 pra cima. O que isso muda tecnicamente no motor dos testes? Convidado: Cara, muda muita coisa "debaixo do capô". O PHP 8.4 trouxe melhorias de reflexão e tipagem que são o sonho de qualquer criador de framework. O Sebastian Bergmann, criador do PHPUnit, aproveitou isso pra garantir que os nossos *test doubles* — os famosos mocks e stubs — sejam validados com um rigor matemático. Tipo, antes você conseguia fazer umas gambiarras que o PHP passava, mas agora, com o sistema de tipos avançado, o PHPUnit valida se o que você tá mockando realmente condiz com a interface antes mesmo de rodar a lógica. É menos erro de "Type Mismatch" em produção e mais segurança no desenvolvimento. Apresentadora: E falando em "acabar com a zona", o grande polêmico da vez: a depreciação do matcher `any()`. Cara, eu confesso, eu já usei muito o `any()` só pra calar uma dependência e fazer o teste passar logo. O PHPUnit 13.2 agora está basicamente dizendo: "Para com isso!". Por que essa mudança é tão importante? Convidado: Pois é, Ju, o `any()` era o "porto seguro" do desenvolvedor apressado, né? (risos). Você botava lá `$mock->expects($this->any())` e pronto, não importava se o método era chamado uma vez, dez vezes ou nenhuma. O problema é que isso oculta o comportamento real do sistema. Se você não se importa com quantas vezes um método é chamado, você tá testando um comportamento ou tá só fazendo um "cala a boca" na dependência? O PHPUnit 13.2 quer que a gente seja intencional. Se você só quer que o objeto retorne um dado, use um Stub. Se você quer garantir que um e-mail foi enviado, use um Mock com `once()`. O `any()` gerava testes ambíguos. E ambiguidade em teste é o primeiro passo pro código virar um legado indomável. Apresentadora: Exato! E essa distinção entre Stub e Mock é algo que o Martin Fowler já falava lá atrás, mas a gente, na correria, enfiava tudo no mesmo saco, né? Como é que o desenvolvedor agora decide entre o `createStub()` e o `createMock()` nessa versão nova? Convidado: Legal você tocar nisso. A regra de bolso agora ficou bem clara e o framework te força a isso. Se o seu teste precisa de um dado pra continuar — tipo, buscar um CEP numa API pra calcular o frete — você usa um Stub. Ele só "provê" o dado. Agora, se o objetivo do teste é verificar uma interação — tipo "será que o log de erro foi registrado quando o banco falhou?" — aí você usa um Mock. A grande vantagem é que testes com Stubs são muito menos "quebradiços". Se você refatorar o código interno e mudar uma chamada de método que não interfere no resultado final, o Stub não vai reclamar. Já o Mock garante que o contrato de comportamento seja seguido à risca. Separar isso deixa o teste mais limpo e, sinceramente, muito mais fácil de ler daqui a seis meses. Apresentadora: Com certeza! E tem um ponto que todo gerente de projeto gosta: performance. Eu vi que teve uma reescrita pesada e que a economia de memória pode chegar a 20% em suítes grandes. Como que essa especialização entre Stub e Mock ajuda nisso? Convidado: É pura eficiência, Juliana. Pensa assim: um Mock precisa de todo um aparato interno pra contar quantas vezes foi chamado, em que ordem, com quais argumentos... isso gasta memória e CPU. Um Stub é muito mais simples; ele só recebe uma instrução de retorno e pronto. Quando você separa os dois, o PHPUnit não precisa criar toda a estrutura de monitoramento para os Stubs. Em projetos gigantes, com cinco, dez mil testes, essa economia de 20% de memória faz o CI rodar muito mais rápido. É menos tempo esperando o "pipeline" terminar e menos custo de servidor. Todo mundo ganha. Apresentadora: Massa demais! E Ricardo, pra gente fechar: pra quem está com um projeto legado e quer migrar pro PHPUnit 13.2 e pro PHP 8.4, qual o seu conselho? Porque vai dar trabalho tirar todos aqueles `any()`, né? Convidado: (Risos) Vai, vai dar um trabalhinho, não vou mentir. Meu conselho é: não tente fazer tudo de uma vez. Comece usando as ferramentas de análise estática, tipo o PHPStan ou Psalm, que já estão se integrando a essas regras. Vá trocando os `any()` por `createStub()` onde for apenas provimento de dados. É um investimento, sabe? O código que você escreve hoje com o PHPUnit 13.2 é um código muito mais documentado. O teste passa a ser uma documentação técnica real da sua intenção. Vale cada hora de refatoração. Apresentadora: Perfeito! O futuro do PHP é explícito e não tem mais volta, né? Ricardo, cara, muito obrigada por esse papo. Foi muito esclarecedor! Convidado: Eu que agradeço, Juliana! Sempre um prazer falar sobre como deixar nosso código mais robusto. Valeu pelo convite! Apresentadora: É isso aí, pessoal! O recado do PHPUnit 13.2 está dado: clareza é melhor que facilidade. Se você quer se aprofundar, dá uma olhada na documentação oficial e já começa a preparar o terreno para o PHP 8.4. Os links vão estar aqui na descrição do episódio. Valeu por sintonizar o Allur, seu podcast de tecnologia favorito. Não esquece de seguir a gente nas redes sociais e compartilhar esse episódio com aquele seu amigo que ainda abusa do `any()` nos testes. A gente se vê no próximo episódio. Tchau!