PHPUnit 13 e Sealed Test Doubles: A Era da Rigidez e Segurança no PHP 8.4

Apresentadora: E aí, pessoal, bem-vindos de volta ao Allur! Eu sou a Juliana Santos e hoje a gente vai mergulhar em um assunto que é o coração da qualidade de software no nosso ecossistema: testes automatizados. Se você trabalha com PHP, sabe que o PHPUnit é praticamente o "ar que a gente respira" quando o assunto é garantir que o código não quebre, né? Mas ó, o jogo mudou. O Sebastian Bergmann e a equipe do PHPUnit acabaram de lançar a versão 13, e ela traz uma mudança de paradigma que está deixando muita gente de cabelo em pé, mas que promete elevar o nível das nossas aplicações. Estamos falando da era da rigidez, do fim da "magia" e, principalmente, dos *Sealed Test Doubles* ou Dublês de Teste Selados. Por que agora o framework exige o PHP 8.4? O que acontece com aquele seu mock que aceitava qualquer coisa? É o que vamos descobrir hoje. Preparem o café, porque hoje o papo é técnico, é denso, mas é essencial para quem quer manter a maturidade nos projetos. Apresentadora: E para destrinchar essa sopa de letrinhas e entender se essa rigidez toda é boa ou ruim, eu trouxe um convidado de peso. Ele é Tech Lead, entusiasta de longa data do TDD e um dos caras que mais manja de arquitetura PHP que eu conheço. Seja muito bem-vindo ao Allur, Rafael Camargo! Rafa, valeu demais por aceitar o convite, cara. Convidado: Valeu, Juliana! É um prazer enorme estar aqui no Allur. Eu acompanho o podcast e adoro como vocês trazem esses temas que, às vezes, parecem pesados, de um jeito bem pé no chão. E olha, falar de PHPUnit 13 e PHP 8.4 é falar sobre o futuro da linguagem, então estou bem empolgado para esse papo. Apresentadora: Massa! E vamos começar pelo começo, Rafa. A primeira coisa que chamou a atenção de todo mundo foi o requisito: PHPUnit 13 exige, no mínimo, o PHP 8.4. Cara, isso é um salto considerável, né? Muita gente ainda está brigando para sair do 7.4 ou 8.1. Por que você acha que o Sebastian Bergmann tomou essa decisão tão drástica de "puxar o sarrafo" logo de cara? Convidado: Pois é, Ju, parece drástico, né? Mas tem um motivo técnico muito forte por trás. O PHP 8.4 trouxe coisas como os *Property Hooks* e melhorias pesadas no sistema de tipos. Quando o PHPUnit exige a versão mais nova, ele para de tentar "simular" comportamentos que a linguagem agora resolve de forma nativa. O PHP evoluiu muito. Antigamente, a gente usava muita "magia" e hacks internos para fazer os mocks funcionarem. Agora, o framework está falando: "Olha, se a engine do PHP já é robusta e tipada, por que eu vou continuar aceitando gambiarra?". É uma forma de forçar o ecossistema a se modernizar. É como se o PHPUnit estivesse falando: "Quer usar as ferramentas mais modernas de teste? Então mantenha sua casa em ordem e atualize sua engine". Apresentadora: Entendi. É tipo aquele empurrãozinho que a gente precisa para não ficar parado no tempo. E aí entra a grande estrela dessa versão, que são os *Sealed Test Doubles*. Explica pra gente, o que é um "dublê selado" na prática? Porque o nome soa meio misterioso, tipo um documento secreto do governo, né? (risos) Convidado: (risos) Verdade! Mas a ideia é bem menos secreta e muito mais segura. Pensa assim: até a versão 12, se você criasse um mock de uma classe, vamos supor, uma classe `Mailer`, e por um erro de digitação ou distração você configurasse um método chamado `enviarEmail` (com 'e' minúsculo), mas na classe real o método fosse `sendEmail` (em inglês), o PHPUnit deixava passar. Ele criava esse método dinamicamente no mock. O teste passava lindo, ficava tudo verde. Mas na hora de rodar no servidor... cabum! Erro de produção, porque o método real nunca existiu. Apresentadora: Nossa, eu já vi isso acontecer mil vezes! É o famoso "falso positivo", né? O teste mente pra você na cara dura. Convidado: Exatamente! Com os *Sealed Test Doubles*, ou dublês selados, isso acabou. Agora, se você tenta configurar uma expectativa para um método que não existe na interface ou na classe original, o PHPUnit trava na hora. Ele "sela" o mock. Se o método não está no contrato oficial da classe, o mock não pode ter. É o fim da criação dinâmica de métodos em tempo de teste. É uma rigidez que traz uma segurança absurda, principalmente em refatorações. Apresentadora: Cara, isso é massa demais! Porque se eu renomeio um método na minha classe principal, eu não preciso nem rodar a lógica complexa do teste pra saber que quebrou. O simples setup do mock já vai me avisar: "Ei, esse método que você está tentando mocar não existe mais". Isso economiza um tempo de debug que não tá no gibi, né? Convidado: Com certeza! E tem outro ponto legal, Ju. Isso força o desenvolvedor a olhar mais para as interfaces. Se o seu mock está dando erro porque o método é privado ou não existe, talvez o problema não seja o teste, mas sim o seu design de código que está bagunçado. O PHPUnit 13 respeita o encapsulamento. Se o método não é acessível, você não deveria estar mocando ele. Acabou aquela festa de ignorar a visibilidade dos métodos só para o teste passar. Apresentadora: É o que o pessoal chama de "ouvir os testes", né? Se o teste está difícil de escrever ou o mock está reclamando, o seu código de produção provavelmente precisa de atenção. Mas me diz uma coisa, Rafa, e o legado? Eu imagino o desespero de quem tem uma suíte de 5 mil testes cheia de "magias" e agora tem que migrar para o PHPUnit 13. Qual o caminho das pedras? Convidado: Olha, não vou mentir, não é um "copiar e colar". Migrar para o 13 exige uma mudança de mentalidade. O primeiro passo é limpar os avisos de depreciação na versão 12. Se o seu código já roda liso no 12 sem avisos, o pulo para o 13 é mais tranquilo. Mas para quem abusava de propriedades dinâmicas nos mocks, vai ter trabalho. O desafio não é só o código, é o time. O time precisa entender que agora o rigor é o novo padrão. A gente tem que parar de ver o teste como algo que "tem que passar de qualquer jeito" e começar a ver como uma especificação técnica rígida. Eu recomendo usar ferramentas como PHPStan ou Psalm antes mesmo de rodar o PHPUnit. Se o PHPStan já te avisa que aquele método não existe, o PHPUnit nem vai precisar te dar o tapa na cara depois. Apresentadora: É um ecossistema de qualidade trabalhando junto, né? Linguagem, análise estática e framework de testes. Agora, Rafa, para a gente fechar esse tópico técnico: além dessa segurança, você acha que isso impacta na performance dos testes? Já que o framework está "mais enxuto" e menos dependente de hacks internos? Convidado: Com certeza impacta. Quando você remove camadas de "mágica" e reflexão pesada que eram necessárias para criar esses comportamentos dinâmicos, o framework fica mais leve. A execução tende a ser mais direta. Mas o ganho real, na minha opinião, não é nem os milissegundos na execução, mas sim a redução da dívida técnica. Sabe aquele código morto que ninguém tem coragem de apagar porque tem um teste que "passa" mas ninguém sabe como? O PHPUnit 13 vai expor essas feridas. Ele vai te mostrar que aquele teste estava testando algo que nem existia. No longo prazo, a manutenibilidade do sistema vai para outro nível. Apresentadora: Sensacional. É basicamente uma faxina geral na casa. Rafa, o papo está incrível, mas a gente está chegando no fim. Se você pudesse dar um conselho final para quem está ouvindo o Allur agora e está com medo dessa "era da rigidez", o que você diria? Convidado: Eu diria: abrace a estrutura! A flexibilidade excessiva do PHP no passado foi o que deu a fama de "linguagem bagunçada" para a gente. O PHP 8.4 e o PHPUnit 13 são a prova de que o PHP é hoje uma linguagem de elite, madura e segura. Não veja a rigidez como um obstáculo, veja como um cinto de segurança. Pode apertar um pouco no começo, mas é o que vai salvar seu projeto de uma regressão boba em produção. Comece atualizando seus pequenos projetos, sinta a diferença e depois leve isso para o trabalho. Vale muito a pena. Apresentadora: Que aula, hein, pessoal? "Abrace a estrutura". Vou levar essa frase comigo. Rafa, muito obrigada mesmo por compartilhar sua experiência aqui no Allur. Foi um prazer enorme. Convidado: Eu que agradeço, Ju! Valeu pelo convite e parabéns pelo podcast. Até a próxima! Apresentadora: E você, ouvinte, está pronto para selar seus dublês de teste? Se quiser saber mais sobre as notas de lançamento do PHPUnit 13 ou ver exemplos de código do que a gente conversou aqui, confira os links na descrição deste episódio. Não esquece de seguir o Allur na sua plataforma de podcast favorita e de compartilhar esse episódio com aquele seu amigo que ainda acha que teste é "perda de tempo". Valeu por sintonizar o Allur, eu sou a Juliana Santos e a gente se vê no próximo episódio. Tchau!