# Probar el código PHP: PHPUnit y Pest

> PHPUnit y Pest explicados: versiones, primeras pruebas, tipos de prueba útiles y por qué las pruebas hacen más seguras las actualizaciones tras PHP2Shell.

Fuente: https://phpsos.de/es/php/php-testen/  
Actualizado: 25/10/2026  
Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6

**En resumen:** PHPUnit es la herramienta estándar para probar código PHP de forma automática; Pest es un framework construido sobre ella, con una escritura más breve. La versión actual es PHPUnit 13 (desde febrero de 2026, a partir de PHP 8.4); Pest está en la versión 5. Las pruebas automáticas no cierran vulnerabilidades del propio PHP, pero hacen predecibles las actualizaciones: tras PHP2Shell y antes del fin del soporte de PHP 8.2 el 31/12/2026, esa es la ventaja decisiva.

## ¿Por qué probar el código PHP?

Para la dirección, el beneficio cabe en una frase: las pruebas hacen los cambios más baratos y seguros. Una prueba automática comprueba en segundos si una función sigue haciendo lo que debe, por ejemplo si un carrito calcula bien o si un inicio de sesión rechaza contraseñas incorrectas. Sin pruebas, lo comprueba una persona a mano, o nadie.

La diferencia se aprecia especialmente en las actualizaciones. Cuando hay que actualizar PHP con urgencia por una vulnerabilidad crítica, muchos operadores dudan porque temen fallos en la tienda o en el portal de clientes. Con un conjunto de pruebas, la actualización se ejecuta primero en un entorno de prueba, las pruebas muestran los problemas y después se pasa a producción.

## PHPUnit: el estándar para las pruebas de PHP

PHPUnit publica una versión principal nueva cada año en febrero. Cada versión exige una versión mínima de PHP y recibe unos dos años de correcciones de errores. Según phpunit.de:

| PHPUnit | Publicación | Requisito de PHP | Correcciones de errores hasta |
|---|---|---|---|
| 13 | 06/02/2026 | desde PHP 8.4 | 04/02/2028 |
| 12 | 07/02/2025 | desde PHP 8.3 | 05/02/2027 |
| 11 | 02/02/2024 | desde PHP 8.2 | 06/02/2026 |
| 10 | 03/02/2023 | desde PHP 8.1 | 07/02/2025 |

La tabla muestra una relación práctica: un proyecto que aún usa PHPUnit 10 suele ejecutarse también en una versión antigua de PHP. Las herramientas de prueba y la versión de PHP deberían actualizarse a la vez. PHPUnit suele instalarse mediante [Composer](https://phpsos.de/es/php/composer/) como dependencia de desarrollo.

## Una primera prueba con PHPUnit

Una prueba es una clase que hereda de `PHPUnit\Framework\TestCase`. Los métodos de prueba son públicos y empiezan por `test`; como alternativa se marcan con el atributo `#[Test]`. El ejemplo comprueba una función sencilla de cálculo de precios:

```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));
    }
}
```

El data provider suministra varios casos para la misma prueba. Según la documentación de PHPUnit, debe ser público y estático. Se calcula en céntimos como número entero, para que no haya errores de redondeo por números de coma flotante. El conjunto se ejecuta con `./vendor/bin/phpunit` cuando PHPUnit está instalado mediante Composer.

## Pest: la misma base, una escritura más breve

Según su documentación, Pest está construido sobre PHPUnit. Las pruebas se escriben como funciones con `it()` o `test()` y las expectativas con `expect()`. Pest 5 exige PHP 8.4. La instalación según la documentación:

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

La misma prueba con la escritura de Pest:

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

El plugin `pestphp/pest-plugin-drift` convierte en gran parte de forma automática las pruebas de PHPUnit existentes. Qué escritura elige un equipo es cuestión de gusto; lo decisivo es que las pruebas se ejecuten con regularidad.

## Qué tipos de prueba tienen sentido

1. **Pruebas unitarias:** comprueban funciones y clases individuales sin base de datos ni red.
2. **Pruebas de integración:** comprueban la interacción con la base de datos, el sistema de archivos o las interfaces.
3. **Pruebas funcionales por HTTP:** acceden a páginas y formularios como lo hace un navegador.
4. **Pruebas de regresión de seguridad:** fijan los fallos corregidos, por ejemplo que las salidas se escapen con `htmlspecialchars()` o que un inicio de sesión falle con una contraseña incorrecta.
5. **Pruebas de humo tras el despliegue:** pocas comprobaciones rápidas de que el sitio en producción responde tras una actualización.

Como complemento de las pruebas, el [análisis estático con PHPStan y Psalm](https://phpsos.de/es/php/statische-analyse/) encuentra errores sin ejecutar el código.

## Las pruebas como red de seguridad para las actualizaciones y PHP2Shell

PHP2Shell ha mostrado lo corto que puede ser el tiempo entre la publicación y la presión por actuar: anuncio el 20/10/2026, parches el 21/10/2026, nivel de alerta naranja del BSI. Quien tenía un conjunto de pruebas pudo aplicar PHP 8.4.27 u 8.3.36 en un entorno de prueba, ejecutar las pruebas y pasar a producción el mismo día. Sin pruebas, a menudo solo quedaba elegir entre una actualización sin comprobar y una vulnerabilidad abierta.

El beneficio es aún mayor en un cambio de versión principal. Para PHP 8.1 y anteriores ya no hay actualizaciones oficiales, y PHP 8.2 termina el 31/12/2026, como explica la página [PHP End of Life](https://phpsos.de/es/ratgeber/php-end-of-life-risiken/). Una ejecución de pruebas contra la versión de destino muestra pronto qué funciones obsoletas hay que sustituir. Es útil una canalización de CI que ejecute las pruebas contra varias versiones de PHP, además de echar un vistazo a los release candidates como PHP 8.6.0, aunque nunca en producción.

> **Consejo:**
> Escriba una prueba por cada fallo de seguridad corregido en su aplicación. Así se asegura de que el mismo fallo no vuelva con un cambio posterior.

## ¿Cómo ayuda PHP SOS en concreto?

En la [migración desde PHP 8.1 y anteriores](https://phpsos.de/es/leistungen/php-migration-legacy/) y en las actualizaciones continuas colaboramos así:

- **Valorar el estado actual:** ¿qué pruebas hay, qué versión de PHP y de PHPUnit se ejecutan, dónde faltan pruebas para procesos críticos?
- **Crear una cobertura mínima:** junto con su equipo de desarrollo o su agencia, aseguramos con pruebas el inicio de sesión, los formularios y los procesos de pedido.
- **Probar las actualizaciones:** las versiones nuevas de PHP se ejecutan primero en un entorno de prueba contra el conjunto de pruebas.
- **Documentar el resultado:** recibirá los resultados de las pruebas y las versiones como justificante del paso de parcheo o de migración.


## Preguntas frecuentes

**¿Qué versión de PHPUnit necesito?**  
Depende de su versión de PHP. PHPUnit 13 exige PHP 8.4, PHPUnit 12 exige PHP 8.3 y PHPUnit 11 exige PHP 8.2. La tabla actual figura en phpunit.de, en las versiones con soporte.

**¿Es Pest un sustituto de PHPUnit?**  
Según su propia documentación, Pest está construido sobre PHPUnit y ofrece una escritura más breve. Las pruebas de PHPUnit existentes pueden convertirse en gran parte de forma automática con el plugin Drift; algunas hay que adaptarlas a mano.

**¿Ayudan las pruebas frente a vulnerabilidades del propio PHP?**  
No directamente. Vulnerabilidades como PHP2Shell están en el intérprete y se cierran con una actualización de PHP. Pero las pruebas hacen que pueda aplicar esa actualización con rapidez, sin temor a fallos inadvertidos en la aplicación.

**¿Cuántas pruebas son suficientes?**  
No hay una cifra fija. Lo sensato es cubrir primero los caminos críticos para el negocio: inicio de sesión, pedidos, formularios, interfaces. Después, la cobertura crece con cada cambio y con cada fallo corregido.

## Fuentes

- [PHPUnit](https://phpunit.de/)
- [Pest](https://pestphp.com/)
- [php.net: versiones de PHP con soporte](https://www.php.net/supported-versions.php)