# Testar código PHP: PHPUnit e Pest

> PHPUnit e Pest explicados: versões, primeiros testes, tipos de teste úteis e por que os testes tornam as atualizações após o PHP2Shell mais seguras e rápidas.

Fonte: https://phpsos.de/pt/php/php-testen/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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:

| PHPUnit | Lançado | Requisito de PHP | Correções de erros até |
|---|---|---|---|
| 13 | 06/02/2026 | a partir do PHP 8.4 | 04/02/2028 |
| 12 | 07/02/2025 | a partir do PHP 8.3 | 05/02/2027 |
| 11 | 02/02/2024 | a partir do PHP 8.2 | 06/02/2026 |
| 10 | 03/02/2023 | a partir do PHP 8.1 | 07/02/2025 |

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](https://phpsos.de/pt/php/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
<?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:

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

O mesmo teste na sintaxe do Pest:

```php
<?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](https://phpsos.de/pt/php/statische-analyse/) 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](https://phpsos.de/pt/ratgeber/php-end-of-life-risiken/). 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.

> **Dica:**
> Escreva um teste para cada erro de segurança corrigido na sua aplicação. Assim garante que o mesmo erro não regressa numa alteração posterior.

## Como ajuda concretamente a PHP SOS?

Na [migração do PHP 8.1 e anteriores](https://phpsos.de/pt/leistungen/php-migration-legacy/) 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

**Que versão do PHPUnit preciso?**  
Depende da sua versão do PHP. O PHPUnit 13 exige o PHP 8.4, o PHPUnit 12 o PHP 8.3 e o PHPUnit 11 o PHP 8.2. A tabela atual está em phpunit.de, nas versões suportadas.

**O Pest substitui o PHPUnit?**  
Segundo a sua própria documentação, o Pest assenta no PHPUnit e oferece uma sintaxe mais curta. Os testes PHPUnit existentes podem, em grande parte, ser convertidos automaticamente com o plugin Drift; alguns têm de ser ajustados à mão.

**Os testes ajudam contra vulnerabilidades do próprio PHP?**  
Não diretamente. Vulnerabilidades como o PHP2Shell estão no interpretador e fecham-se com uma atualização do PHP. Os testes garantem, porém, que pode aplicar essa atualização depressa, sem receio de erros não detetados na aplicação.

**Quantos testes são suficientes?**  
Não há um número fixo. O sensato é cobrir primeiro os percursos críticos para o negócio: início de sessão, encomenda, formulários, interfaces. Depois, a cobertura de testes cresce com cada alteração e cada erro corrigido.

## Fontes

- [PHPUnit](https://phpunit.de/)
- [Pest](https://pestphp.com/)
- [php.net: versões do PHP suportadas](https://www.php.net/supported-versions.php)