Programing
Pest 4.7: Lidando com Testes Flaky, Asserções Arquiteturais e Melhorias de Performance para Testes PHP Mais Robustos
Published:
•
Duration: 7:10
0:00
0:00
Transcript
Apresentadora: Juliana Santos
Convidado: Rafael Camargo (Engenheiro de Software Sênior e Especialista em Ecossistema Laravel)
Apresentadora: E aí, pessoal, bem-vindos de volta ao Allur, o seu ponto de encontro sobre tecnologia, Go, mobile e, claro, muito PHP e Laravel! Eu sou a Juliana Santos e hoje a gente vai falar sobre algo que é o sonho — e às vezes o pesadelo — de todo desenvolvedor: testes automatizados. Sabe aquele momento em que o seu CI/CD fica vermelho, você não mudou nada, roda de novo e ele fica verde? Pois é, os famosos testes "flaky" ou instáveis. O Pest, que já é o queridinho da comunidade PHP, lançou a versão 4.7 e ela veio com o pé na porta para resolver isso e ainda dar uma aula de arquitetura no seu código. A gente vai entender como o Pest está deixando de ser apenas um "test runner" bonitinho para se tornar um verdadeiro guardião da qualidade do nosso software. Se você quer parar de perder tempo investigando falha fantasma e quer garantir que seu projeto siga padrões de design rigorosos sem esforço, fica com a gente.
Apresentadora: E para mergulhar nessas novidades comigo, eu recebo hoje o Rafael Camargo. O Rafa é Tech Lead, respira Laravel há anos e é um entusiasta ferrenho de testes e boas práticas. Rafa, muito massa ter você aqui no Allur!
Convidado: Valeu demais pelo convite, Ju! É um prazer estar aqui. Cara, eu sou fã do Allur e falar de Pest é sempre um prazer, porque é uma ferramenta que mudou muito o meu dia a dia e o da minha equipe. A versão 4.7 trouxe umas paradas que a gente estava esperando faz tempo, então o papo hoje vai ser bom!
Apresentadora: Com certeza! E Rafa, vamos começar pelo que mais dói: os testes flaky. Cara, não tem nada mais frustrante do que você estar ali, focado, sobe o PR e o pipeline falha do nada. Aí você dá um "re-run" e passa. O que o Pest 4.7 trouxe de concreto pra gente parar de passar esse nervoso?
Convidado: Nossa, Juliana, nem me fala. O teste flaky é tipo aquele barulhinho estranho no carro que só aparece quando você não está no mecânico, sabe? É um teste não determinístico. No CI, isso é um veneno, porque o time começa a ignorar o erro. O cara pensa: "Ah, falhou de novo? Deve ser o banco, roda aí de novo que passa". E é nesse "roda aí de novo" que um bug real passa batido. O Pest 4.7 agora tem a flag `--retry` de forma nativa. Tipo assim, agora você pode rodar, por exemplo, `./vendor/bin/pest --retry=3`. Se o teste falhar, o Pest tenta de novo ali na hora.
Apresentadora: Mas espera aí, isso não é "varrer o problema pra debaixo do tapete"? Se eu só reexecutar até passar, eu não tô escondendo que meu teste tá instável?
Convidado: Essa é a sacada! O Pest não esconde o problema. Se ele falhar na primeira e passar na segunda, ele marca o teste no relatório como "retried". Ou seja, o seu pipeline passa, você não trava a entrega, mas você tem ali um relatório gritando: "Ei, esse teste aqui é instável, dá uma olhada nele depois!". É o equilíbrio perfeito entre não travar o deploy por um ruído de rede, mas ainda assim identificar onde o código está frágil. Ajuda muito a manter a confiança na suíte.
Apresentadora: Massa! Isso é muito útil, especialmente em testes de integração que dependem de algum serviço externo ou banco. Agora, mudando de assunto, mas ainda em qualidade... eu vi que eles capricharam nas asserções arquiteturais. Eu achei isso genial, porque a gente sempre tenta manter o código limpo no "grito" ou no code review, né?
Convidado: Exatamente! No code review a gente sempre fala: "Pô, fulano, não usa Controller dentro do Domain" ou "Essa model não devia conhecer a camada de UI". Mas o humano falha, né? O Pest 4.7 agora permite que você escreva testes para a sua *arquitetura*. Você consegue definir regras do tipo: "O namespace tal não pode usar o namespace qual". E é uma linha de código, Ju! É muito legível, parece que você está escrevendo uma frase em inglês.
Apresentadora: Tipo aquele exemplo de proibir o `dd()` ou o `dump()` de chegar em produção? Eu já vi muito projeto com `var_dump` esquecido que derrubou performance.
Convidado: Cara, sim! Esse é o clássico. Você cria um teste arquitetural rapidinho: `expect()->not->toBeUsed()`. Pronto. Se alguém esquecer um debug no código, o teste quebra na hora. Outro exemplo legal é pra quem usa DDD ou Arquitetura Hexagonal. Você consegue garantir que sua camada de Domínio nunca, jamais, importe nada do `App\Http`. Se alguém tentar dar um `use` lá, o teste aponta a violação. É como ter um arquiteto de software revisando seu código em tempo real, toda vez que você roda a suíte.
Apresentadora: Isso é muito poderoso pra times grandes, né? Mantém a consistência sem precisar de um manual de 50 páginas que ninguém lê. E sobre performance, Rafa? Porque quanto mais teste a gente coloca, mais lento fica o processo. O Pest 4.7 deu uma tunada no motor?
Convidado: Com certeza. O feedback loop é sagrado pro desenvolvedor. Se o teste demora 10 minutos pra rodar, a gente perde o foco, vai pro café, olha o Twitter... O Pest 4.7 trouxe otimizações internas bem agressivas. Eles melhoraram muito o consumo de memória e a velocidade de execução, especialmente em suítes grandes. Em alguns projetos que eu testei, a redução no tempo de CI foi bem perceptível. E o legal é que não é só velocidade bruta, é DX, né? A experiência do desenvolvedor. As mensagens de erro estão mais claras, o console está mais limpo. É aquela polida final que faz você gostar de usar a ferramenta.
Apresentadora: Eu sinto que o Pest está elevando o nível do ecossistema PHP. Antes a gente via o pessoal de outras linguagens tirando sarro, e hoje o Pest é referência até pra frameworks de fora.
Convidado: Total! O Pest pegou o que o PHPUnit tinha de sólido — porque ele ainda roda por baixo do Pest — e colocou uma camada de elegância e funcionalidade que é difícil de bater. Essas novas ferramentas de arquitetura e o gerenciamento de testes flaky mostram que eles estão ouvindo quem está no campo de batalha, sabe? Quem lida com pipeline quebrando às 6 da tarde de uma sexta-feira.
Apresentadora: Rafa, pra gente fechar: pra quem ainda está no PHPUnit purista ou está começando agora com Pest, qual seu conselho pra adotar essas novidades da 4.7?
Convidado: Cara, meu conselho é: comece pequeno. Instala a versão nova, e a primeira coisa que você faz é criar um arquivo de teste de arquitetura. Protege o seu domínio, proíbe os `dd()` da vida. Você vai ver que em 10 minutos seu projeto já vai estar num nível de maturidade bem maior. E pro pessoal que sofre com CI instável, testa o `--retry`. Não como desculpa pra código ruim, mas como uma ferramenta pra dar paz de espírito pro time. O Pest está aí pra facilitar nossa vida, não pra ser mais um peso.
Apresentadora: Sensacional, Rafa! Eu saio daqui até com vontade de refatorar uns testes meus que estão meio capengas. Galera, as notas de lançamento do Pest 4.7 estão lá no GitHub oficial deles, vale muito a pena ler cada detalhe. Rafa, obrigada demais pelo papo, foi massa ter você aqui!
Convidado: Eu que agradeço, Ju! Valeu mesmo e bora testar esse código, galera!
Apresentadora: É isso aí! E valeu por sintonizar o Allur. Se você curtiu esse episódio, compartilha com aquele seu colega que vive reclamando do CI vermelho. A gente se vê no próximo episódio. Tchau!
Tags
software engineering
php
testing
laravel
performance
pest