Controle a refatoração de seu sistema legado com testes de arquitetura PEST

O PEST surgiu da imaginação de Nuno Maduro e Luke Dowling em 2021, com a missão de, aparentemente, trazer o estilo de testes semelhante ao do JEST do mundo do JavaScript para o mundo do PHP por meio do Laravel. Desde então, houve dois lançamentos importantes do projeto e diversos novos recursos que chamaram a atenção.

Para mim, foi a introdução da arquitetura testes de arquitetura que eu nunca tinha visto antes. Claro, você deve escrever testes para absolutamente tudo o que faz (e você deve mesmo!), mas de que adiantaria escrever testes sobre a própria estrutura da aplicação? Bem, ao iniciar um projeto do zero: provavelmente não adiantaria muita coisa. Mas é aí que entra a beleza disso: e se a gente introduzisse isso em um grande e antigo código legado tipo “espaguete” que precisa de refatoração gerenciada? Agora sim! Neste artigo, vamos dar uma olhada nos pontos de partida mais fáceis para dar início a uma refatoração de código legado com os Testes de Arquitetura do PEST.

Uma mensagem para os gerentes de engenharia

O que ele consegue fazer? Bem, usando a função função `arch()` , podemos fazer várias coisas com a API de Expectação do PEST:

• Definir em que casos as classes podem ser estendidas e em que casos não podem

• Defina onde suas interfaces estão localizadas

• Definir quais classes devem e quais não devem usar traits

• Refatorar para remover o chamado acidental die() ou dump() antes que algo como o PHPStan/Psalm seja executado

• Faça com que sua aplicação siga as convenções de nomenclatura do Laravel

São muitas coisas prontas para uso. Então, digamos que você assuma um novo projeto e, em uma hora, já possa iniciar a refatoração com testes de alto nível. O cenário ideal que você almejaria ao assumir uma base de código legada seria, portanto:

• Elabore o guia de estilo que defina como a lógica do novo aplicativo deve ser estruturada e funcionar

• Comece a escrever testes PEST que falhem para implementar isso.

De certa forma, o que me parece estar sendo proposto é uma reimplementação do Desenvolvimento Orientado a Comportamentos (Behaviour Driven Development). Pense no guia de estilo como seus testes no estilo Gherkin, que você depois traduz em testes de unidade e de integração no PEST.

Liderar pelo exemplo

Tudo isso fica apenas no plano teórico sem exemplos, então vamos partir do princípio de que você tem uma base de código Laravel legada. Antes de colocar os testes em prática, você vai querer usar uma ferramenta de refatoração automática, como o RectorPHP, para aplicar conjuntos de regras PHP que vão adequar o código às convenções modernas, ou então pode usar o Laravel Shift. A partir daí, podemos introduzir o PEST usando o Composer:

composer require pestphp/pest --dev --with-all-dependencies

E, em seguida, você pode inicializar uma nova configuração do PEST:

./vendor/bin/pest --init

Isso criará seu Pest.php , que, se você estiver familiarizado com o uso do PHPUnit, é o equivalente ao arquivo de configuração phpunit.xml. É hora de começar a trabalhar.

Hum... E agora?

Does Your Code Look Like This?É isso aí. O motivo pelo qual você segue carreira na área de tecnologia. Você vive para herdar um aplicativo Laravel de 15 anos que tem rotas de depuração expondo completamente os comandos principais da CLI, apresenta dependências circulares e, provavelmente, contém DB::raw('SELECT * FROM nightmare WHERE refactoring = 1'); espalhado por toda parte.

Vamos criar uma regra segundo a qual quaisquer comandos de depuração inseridos acidentalmente no código-fonte devem ser executados antes que qualquer progresso possa ser feito. Isso é o mínimo necessário, certo? Essa funcionalidade já está integrada ao PEST; portanto, primeiro crie um teste na linha de comando usando o console:

php artisan pest:test DebbugingRulesetTest

Execute o executor de testes:

php artisan test

Você vai perceber que isso vai dar errado, pois o PEST tentou gerar o código de forma padronizada. Acesse o arquivo de teste DebuggingRulesetTest.php e substitua o código da seguinte maneira:

<?php

arch()->preset()->php();

Execute os testes e, como você herdou uma bagunça teórica, imagino que o PEST vai começar a reclamar com você.

Whoops, No Debugging Code Here, Please!

Alt:

Já definimos a primeira regra de refatoração; agora precisamos aplicá-la. Existem várias maneiras de fazer isso; em ambientes de produção, é comum que um executador de integração contínua, como o Bitbucket Pipelines da Atlassian, o CI/CD do GitLab ou o GitHub Actions, acione as regras para permitir a fusão de pull requests. No entanto, vamos implementar as regras mais rígidas, nas quais nem mesmo é possível fazer um commit no código sem que o PEST seja satisfeito.

Isso é feito por meio dos hooks do Git. Crie um novo hook pre-commit com este comando:

cd my-code/.git/hooks

// Windows Users Only
echo. > pre-commit

// Unix-like Users Only
touch pre-commit
chmod +x pre-commit

Abra o arquivo pre-commit criado na etapa anterior em um editor de texto ou IDE e adicione o código para executar o PEST:

#!/bin/sh

echo "Pre Commit Test Runner Fired"

# Detect OS

if [ "$(uname 2>/dev/null)" = "Linux" ] || [ "$(uname 2>/dev/null)" = "Darwin" ]; then u
    echo "Running Unix-like"
    CMD="./vendor/bin/pest"
else
    echo "Running Windows"
    CMD="vendor\\bin\\pest.bat"
fi

$CMD
RESULT=$?

if [ $RESULT -ne 0 ]; then
    echo "Cannot Commit, Tests Failed"
    exit 1
fi

echo "Commit Success"

exit 0

O arquivo pre-commit é um nome de arquivo reservado que o git verifica para diversas ações — nesse caso, qualquer que seja o conteúdo desse arquivo, ele será executado sempre que um usuário tentar fazer um commit na base de código.

Vá em frente, tente enviar uma alteração no código e veja o que acontece!

Isso nos deixa bem preparados para dar início à nossa refatoração como ponto de partida. Já abordamos a configuração, então agora é só uma questão de utilizar os métodos da API de testes de arquitetura do PEST. Em nosso teste, podemos adicionar mais algumas regras de alto nível:

<?php

arch()->preset()->php(); // our previous rules
arch()->preset()->security();
arch()->preset()->strict();

Adicionei algumas regras aqui, que você pode ver em detalhes no código-fonte do PEST. A primeira delas, security(), vai ajudar muito na sua refatoração inicial: ela faz com que o código falhe e identifica onde há falhas graves de segurança. Isso inclui o uso de métodos da Biblioteca Padrão do PHP que foram substituídos por motivos de segurança, como 

• md5(): Usos do tipo MD5 realmente precisam ser substituídos pelo SHA256; portanto, se você tiver dados como IDs de sessão ou identificadores exclusivos de banco de dados, eles precisam passar por uma refatoração do tipo ETL 

• rand(): A função aleatória original do PHP não é, na verdade, aleatória

• shell_exec(): Chamar o shell da máquina host é, muito provavelmente, a pior coisa que você pode fazer. É claro que, em algum momento, você precisará fazer isso, mas a ideia aqui é que você use o console do Laravel e os métodos encapsulados por motivos de segurança, em vez de permitir que código legado destrua seu servidor sem controle.

Considerando o número de regras contidas apenas nesses pontos de partida, acho que isso dá o trabalho de refatoração de alguns sprints! Há todo tipo de coisa que acho que você poderia fazer com isso, já que o PEST permite uma infinidade de testes na API Expectation.

Conclusão

Além dos testes de arquitetura, o PEST 3 também trouxe a introdução dos testes de mutação, assunto para outra ocasião. A quantidade de recursos que o PEST oferece, no entanto, é realmente um arsenal completo de ferramentas para quem está lidando com projetos legados. Na Vonage, somos apaixonados por testes; que tal bater um papo conosco sobre PHP? Junte-se à nossa Comunidade de Desenvolvedores no Slack, siga-nos no X (antigo Twitter) ou inscreva-se em nosso Boletim Informativo para Desenvolvedores. Fique conectado, compartilhe seu progresso e acompanhe as últimas notícias, dicas e eventos para desenvolvedores!