Testar código PHP: PHPUnit e Pest

Em resumo: O PHPUnit é a ferramenta padrão para testar código PHP automaticamente; o Pest é uma framework que assenta nele, com sintaxe mais curta. Atualmente, o PHPUnit está na versão 13 (desde fevereiro de 2026, a partir do PHP 8.4) e o Pest na versão 5. Os testes automáticos não fecham vulnerabilidades do próprio PHP, mas tornam as atualizações previsíveis: depois do PHP2Shell e antes do fim do suporte do PHP 8.2, a 31/12/2026, é esta a vantagem decisiva.

Porquê testar código PHP?

Para a gestão, o benefício resume-se numa frase: os testes tornam as alterações mais baratas e mais seguras. Um teste automático verifica em segundos se uma função ainda faz o que deve, por exemplo se um carrinho de compras calcula bem ou se um início de sessão recusa palavras-passe erradas. Sem testes, isso verifica-o uma pessoa à mão, ou ninguém.

A diferença torna-se particularmente clara nas atualizações. Quando o PHP tem de ser atualizado a curto prazo devido a uma vulnerabilidade crítica, muitos operadores hesitam, porque receiam erros na loja ou no portal de clientes. Com uma suite de testes, a atualização corre primeiro num ambiente de teste, os testes mostram os problemas e só depois se vai para produção.

PHPUnit: o padrão para testes PHP

O PHPUnit publica todos os anos, em fevereiro, uma nova versão principal. Cada versão exige uma versão mínima do PHP e recebe cerca de dois anos de correções de erros. Segundo o phpunit.de, aplica-se:

A tabela mostra uma relação prática: um projeto que ainda usa o PHPUnit 10 corre, em regra, também numa versão antiga do PHP. As ferramentas de teste e a versão do PHP devem ser elevadas em conjunto. O PHPUnit instala-se habitualmente através do Composer, como dependência de desenvolvimento.

Um primeiro teste com o PHPUnit

Um teste é uma classe que herda de PHPUnit\Framework\TestCase. Os métodos de teste são públicos e começam por test; em alternativa, marcam-se com o atributo #[Test]. O exemplo verifica uma função simples de cálculo de preços:

<?php declare(strict_types=1);

use PHPUnit\Framework\Attributes\DataProvider;
use PHPUnit\Framework\TestCase;

final class BruttopreisTest extends TestCase
{
    public static function preise(): array
    {
        return [
            'Normalsatz'   => [10000, 19, 11900],
            'Ermäßigt'     => [10000, 7, 10700],
            'Null bleibt Null' => [0, 19, 0],
        ];
    }

    #[DataProvider('preise')]
    public function testBruttopreisInCent(int $netto, int $satz, int $erwartet): void
    {
        $this->assertSame($erwartet, bruttopreis($netto, $satz));
    }
}

O data provider fornece vários casos para o mesmo teste. Segundo a documentação do PHPUnit, tem de ser público e estático. Calcula-se em cêntimos, como número inteiro, para que não surjam erros de arredondamento por números de vírgula flutuante. A suite executa-se com ./vendor/bin/phpunit, se o PHPUnit estiver instalado através do Composer.

Pest: a mesma base, sintaxe mais curta

Segundo a documentação, o Pest assenta no PHPUnit. Os testes escrevem-se como funções com it() ou test() e as expectativas com expect(). O Pest 5 exige o PHP 8.4. A instalação, segundo a documentação:

composer remove phpunit/phpunit
composer require pestphp/pest --dev --with-all-dependencies
./vendor/bin/pest --init

O mesmo teste na sintaxe do Pest:

<?php
it('berechnet den Bruttopreis zum Normalsatz', function () {
    expect(bruttopreis(10000, 19))->toBe(11900);
});

Os testes PHPUnit existentes são, em grande parte, convertidos automaticamente pelo plugin pestphp/pest-plugin-drift. Que sintaxe uma equipa escolhe é uma questão de gosto; o decisivo é que os testes corram com regularidade.

Que tipos de teste são úteis

1. Testes unitários: verificam funções e classes individuais, sem base de dados nem rede.
2. Testes de integração: verificam a interação com a base de dados, o sistema de ficheiros ou interfaces.
3. Testes funcionais via HTTP: chamam páginas e formulários como o faz um navegador.
4. Testes de regressão de segurança: fixam erros corrigidos, por exemplo que as saídas são escapadas com htmlspecialchars() ou que um início de sessão falha após uma palavra-passe errada.
5. Smoke tests após o deployment: poucas verificações rápidas de que o site em produção responde depois de uma atualização.

Como complemento dos testes, a análise estática com PHPStan e Psalm encontra erros sem executar o código.

Os testes como rede de segurança para atualizações e o PHP2Shell

O PHP2Shell mostrou como pode ser curto o tempo entre a publicação e a pressão para agir: anúncio a 20/10/2026, patches a 21/10/2026, nível de alerta laranja do BSI. Quem tinha uma suite de testes pôde aplicar o PHP 8.4.27 ou 8.3.36 num ambiente de teste, executar os testes e entrar em produção no mesmo dia. Sem testes, restava muitas vezes apenas a escolha entre uma atualização não verificada e uma vulnerabilidade aberta.

O benefício é ainda maior na mudança de versão principal. Para o PHP 8.1 e anteriores já não existem atualizações oficiais, e o PHP 8.2 termina a 31/12/2026, como explica a página Fim de vida do PHP. Uma execução de testes contra a versão de destino mostra cedo que funções obsoletas têm de ser substituídas. É sensata uma pipeline de CI que corra os testes contra várias versões do PHP, além de uma olhadela a release candidates como o PHP 8.6.0, mas nunca em produção.

Como ajuda concretamente a PHP SOS?

Na migração do PHP 8.1 e anteriores e nas atualizações em curso, apoiamos assim:

• Avaliar o estado atual: que testes existem, que versões de PHP e de PHPUnit correm, onde faltam testes para fluxos críticos?
• Criar uma cobertura mínima: em conjunto com a sua equipa de desenvolvimento ou agência, protegemos com testes o início de sessão, os formulários e os percursos de encomenda.
• Testar as atualizações: as novas versões do PHP correm primeiro num ambiente de teste, contra a suite.
• Documentar o resultado: recebe resultados de testes e estados de versões como prova do passo de patch ou de migração.

Perguntas frequentes

Fontes

• PHPUnit
• Pest
• php.net: versões do PHP suportadas