Convertendo seu conjunto de testes para PEST

Mudar a maneira como escrevo código por meio do Desenvolvimento Orientado a Testes, francamente, transformou minhas habilidades como programador. De repente, passei a ser capaz de escrever serviços e funcionalidades com confiança — é um mistério para mim por que tantas empresas ainda “não têm tempo para fazer testes”. Por muito tempo, o PHPUnit tem sido a ferramenta padrão na hora de escrever PHP com TDD.

Recentemente, surgiu um novo projeto que poderia mudar essa situação. Há uma boa documentação e uma comunidade de meetups se formando em torno dele, o que o torna uma opção atraente para os desenvolvedores. Estou me referindo, é claro, ao PEST, então resolvi testá-lo em nosso próprio SDK PHP da Vonage.

A Suíte Current

Nosso SDK PHP da Vonage tem sido cuidadosamente mantido ao longo dos anos e, por isso, contém um conjunto completo de testes. Embora seu escopo não seja do “nível empresarial”, é, mesmo assim, um exercício útil para testar o PEST.

O conjunto atual neste este branch possui 831 testes aprovados, que executam 4.039 asserções. Há 9 testes ignorados e 15 testes incompletos. O tempo total de execução é de 13:54 no PHP8.

Screenshot of total tests showing 9 skipped and 15 incomplete tests.

Só para constar, ele funciona muito bem, e um desses testes é, na verdade, um teste de tempo limite que aumenta a duração. O objetivo aqui não é melhorar o executador, mas sim alterá-lo para ver o que acontece. Nossa primeira etapa é instalar o PEST e executá-lo. Uma das características mais importantes do PEST a ser observada é que ele é totalmente compatível com versões anteriores do PHPUnite, portanto, pode ser usado de forma intercambiável, independentemente da sintaxe que você estiver usando. Isso nos permite instalar o PEST, executá-lo para ver os resultados e, possivelmente, tentar implementar os recentes recente .

Para instalar o PEST, executo o seguinte na linha de comando:

Parece enganosamente fácil que, com apenas um comando do Composer, eu já possa executar o PEST. Vale ressaltar, no entanto, que este repositório no qual ele será executado já possui alguns pré-requisitos — um deles é a versão mínima do PHP 7.3. O PEST já exige que a versão mínima do PHP seja 7.3 ou superior, portanto, não é necessário fazer nenhum ajuste para mantê-lo atualizado.

É hora de executar o PEST e ver o que acontece:

A primeira coisa que você vai notar é que o PEST usa um formato de saída semelhante ao --testdox argumento para formatar a saída do PHPUnit. A saída dele é bem legal:

Test screenshot, showing a time of 13.21 seconds.

Hmm, então 13,28 segundos, né? Bem, na verdade, isso já é mais rápido só com o executador. E se tentarmos usar o recurso de execução paralela do PEST? Ele vem como um pacote separado, então vamos baixá-lo:

E agora, para executá-lo:

E... ah. Bem, parece que nossa sorte acabou:

Screenshot of a PHP bug.

Uma rápida pesquisa no Google revela que existe um bug no próprio PHP relacionado a isso, conforme documentado no registro de problemas do PHPUnit:

https://github.com/sebastianbergmann/phpunit/issues/4305

Acho que esse é o preço que pagamos por estarmos sempre na vanguarda.

Photo of frustrated person looking at their laptop screen.

Sintaxe do PHPUnit vs. PEST

Tenho experimentado o executador de testes, mas ainda não mostrei o código nem expliquei qual é, na verdade, o objetivo do PEST.

Membro do núcleo do Laravel Nuno Madro criou o PEST como uma nova estrutura inspirada na sintaxe do framework . Isso está em total sintonia com a tendência atual do PHP (e especialmente do Laravel) de migrar para uma sintaxe mais funcional e baseada em closures, semelhante à forma como o JavaScript é escrito. Portanto, faz todo o sentido que seus testes de backend em PHP para sua aplicação web full stack sejam escritos em uma sintaxe semelhante à dos testes de front-end. Aqui está um exemplo de “antes e depois” do SDK PHP da Vonage:

class NumberTest extends VonageTestCase  
{  

 /**  
 * @var Number;  
 */
 protected $number;  
  
 public function setUp(): void  
 {  
	$this->number = new Number('14843331212');  
 }  
 
 public function testNumberConstructor(): void  
 {   
	$this->assertEquals('14843331212', $this->number->getNumber());  
 }

Estamos usando alguns padrões comuns aqui — o método mágico setUp() é executado antes dos testes serem executados; em seguida, usamos assertEquals() , que é uma classe auxiliar do PHPUnit TestCase (no nosso exemplo, VonageTestCase que herda dele em um nível superior).

Agora, vou mostrar o mesmo teste, mas escrito na sintaxe do PEST:

use Vonage\Numbers\Number;  
  
beforeEach(function () {  
   $this->number = new Number();  
});  
  
test('number constructor', function () {  
   expect($this->number->getNumber())->toEqual('14843331212');  
});

Este é um bom exemplo de como o ecossistema do PHP, em geral, está se voltando para o JavaScript em busca de novas ideias — como você pode ver, a sintaxe do PEST é muito semelhante à do JEST. Isso também demonstra um dos valores centrais do PEST, que é ter um encadeamento de métodos mais fluido na API para escrever menos código — uma abordagem cuja filosofia é muito semelhante à do Laravel. Agora temos uma função de ordem superior beforeEach() com um closure em seu interior que será executado antes de cada teste, e agora as estruturas clássicas de funções do PHP do PHPUnit foram substituídas por uma sintaxe de estilo mais funcional. Esse exemplo também mostra como a API de Expectativas foi projetada para encadear asserções de forma legível para humanos, com nomes de métodos como expect(true)->toBe(value) ou expect($variable)->toBeArray().

OK, então, automação?

Vou ser sincero: isso não saiu como eu queria. Mas vou explicar o motivo.

Fiquei sabendo disso pelo Twitter que, na verdade, seria possível usar uma ferramenta para converter automaticamente sua suíte do PHPUnit para o PEST, independentemente de o código estar no Laravel ou não. Então, fui até o Pest Converter e criei um repositório e um branch para testar Quando executado, o Shift cria um novo branch a partir do branch base que você fornecer e gera commits de etapas lógicas para percorrer a sintaxe. Uma das primeiras coisas que precisei fazer foi alterar a test/ pasta para tests/ para que o conversor saiba onde procurar seus testes.

No entanto, ao executar o PEST após a conversão:

Screenshot showing Pest\Exceptions\TestCaseClarrOrTrailNotFound.

Hmm. Então, não foi exatamente um mar de rosas. Vale ressaltar que eu não tinha a menor ideia do que esperar, por alguns motivos:

• O SDK PHP da Vonage é independente de framework

• Isso depende do Profetizar Prophesize

• São utilizadas várias características (traits) do PHP, o que torna o conjunto de testes um pouco mais complexo

Em vez de utilizar a composição tradicional, o PEST segue um padrão diferente de configuração. O PEST possui um pest.php arquivo de configuração que permite especificar funções auxiliares, traits e métodos comuns, como RefreshDatabase. Você também pode especificar em quais pastas deseja que as classes sejam aplicadas, desta forma:

uses(\VonageTest\HTTPTestTrait::class)->in('Secrets');

O motivo pelo qual o conversor PEST não consegue resolver esses casos é a existência de vários casos extremos. Um ponto destacado por Jason McCreary , do Laravel Shift, em nossas conversas de suporte, é que alguns testes definem um contêiner de aplicativo como $this->app, o que entra em conflito com a infraestrutura de aplicativos do Laravel (já que ele não sabe se você tem um aplicativo Laravel ou não).

Conclusões

OK, então, embora o PEST Converter tenha tido dificuldade em automatizar a transferência dos testes, isso me leva a duas conclusões:

• A Laravel Shift, criadora do Pest Converter, já está analisando os casos extremos da nossa biblioteca que eu utilizei e trabalhando em como lidar com eles, mas, mais importante ainda,

• Não execute o conversor se seu conjunto de testes for complexo ou excessivamente elaborado — resolva isso primeiro

Como em qualquer coisa, há riscos em realizar uma refatoração de grande porte por meio da automação. No nosso caso, o risco era estarmos lidando com uma biblioteca PHP “pura”, sem framework. No entanto, o Shift funciona atualizando por meio de um branch de destino e, em seguida, criando o branch “Shift” a partir dele para minimizar o risco. Se não funcionar, não faça a fusão! Você também tem a opção de usar o serviço Human Shift , o que inevitavelmente resultará em um conjunto de bibliotecas totalmente convertido.

O que eu aconselho é que, se você tiver um aplicativo em Symfony ou Laravel, esse conversor foi projetado especificamente para esses casos, então a migração será bastante tranquila.

Você deve adotar o PEST? Como sempre, a decisão é sua. Se você quiser se manter na vanguarda das novidades do PHP, essa é certamente uma opção atraente. No entanto, lembre-se de que a forma como o PEST estrutura sua sintaxe está naturalmente alinhada com a abordagem do Laravel em relação aos fluxos de API; portanto, isso pode confundir seus desenvolvedores caso você utilize outras plataformas populares, como Symfony, CakePHP ou Drupal.