Construir software confiable requiere más que escribir código funcional: implica validar cada componente de manera automatizada. Aquí se muestra paso a paso cómo iniciar un proyecto real en PHP utilizando Composer como gestor de dependencias y PHPUnit como framework de pruebas unitarias, aplicando una metodología donde las pruebas guían la creación del código.
¿Cómo instalar PHPUnit con Composer?
El primer paso es instalar PHPUnit a través de Composer. Desde el terminal se ejecuta el comando composer require --dev phpunit/phpunit [00:38]. Este proceso se conecta a Internet, evalúa el componente solicitado y lo instala de forma automática.
Al finalizar la instalación se generan tres elementos fundamentales:
- El archivo composer.json con la configuración del proyecto.
- La carpeta vendor con las dependencias descargadas.
- El archivo composer.lock que registra las versiones exactas instaladas.
Dentro del composer.json es necesario configurar el autoload con PSR-4 [01:35]. Se define el namespace App\ apuntando a la carpeta src/. Después de guardar estos cambios, se ejecuta composer dump-autoload para registrar la nueva configuración. También conviene agregar los campos name (por ejemplo proveedor/validacion) y description para evitar advertencias del sistema [02:05].
¿Cómo configurar el archivo PHPUnit.xml?
PHPUnit utiliza un archivo de configuración XML llamado phpunit.xml [02:30]. La estructura base incluye:
xml
<?xml version="1.0" encoding="utf-8"?>
<phpunit bootstrap="vendor/autoload.php" colors="true">
<testsuite name="Carpeta de pruebas">
<directory>test</directory>
</testsuite>
</phpunit>
El atributo bootstrap indica que se cargue vendor/autoload.php, exactamente lo mismo que se haría en un index.php tradicional [03:12]. El atributo colors en true permite visualizar los resultados con colores distintivos: verde cuando las pruebas pasan y rojo cuando fallan.
El bloque testsuite define el directorio donde se almacenan las clases de prueba. Para ejecutar las pruebas se usa el comando vendor/bin/phpunit desde el terminal [03:55].
¿Cómo escribir pruebas que guíen la creación del código?
La metodología aplicada aquí sigue el principio de escribir primero el test y después el código. Se crea la carpeta test/ y dentro una clase llamada ValidacionTest.php [04:15]. El estándar indica que las clases de prueba deben terminar con la palabra Test, mientras que la clase que se desea probar no la lleva.
php
<?php
use PHPUnit\Framework\TestCase;
use App\Validacion;
class ValidacionTest extends TestCase
{
public function testEmail()
{
$email = Validacion::email("i@remotos.com");
$this->assertTrue($email);
}
}
La clase extiende de **TestCase**, que es la clase base del *framework* PHPUnit [04:32]. Al ejecutar esta prueba sin haber creado la clase `Validacion`, el resultado es **rojo**: la clase no existe [05:20]. Este error es intencional, ya que las pruebas actúan como guía para saber exactamente qué construir.
### ¿Cómo implementar la clase de validación?
Se crea el archivo `src/Validacion.php` con su *namespace* correspondiente [05:40]:
php
<?php
namespace App;
class Validacion
{
public static function email($valor)
{
return (bool) filter_var($valor, FILTER_VALIDATE_EMAIL);
}
}
La función **filter_var** es nativa de PHP y permite filtrar variables según constantes predefinidas [06:15]. En este caso se utiliza `FILTER_VALIDATE_EMAIL` para verificar que el formato del correo electrónico sea válido. El resultado se convierte a **booleano** con `(bool)` para retornar `true` o `false`.
Al ejecutar nuevamente las pruebas, el resultado pasa de rojo a **verde** [06:38].
### ¿Cómo probar casos negativos?
También es posible validar entradas incorrectas. Por ejemplo, un correo con dos arrobas como `i@@remotos.com` debería fallar [06:55]:
php
public function testEmailIncorrecto()
{
$email = Validacion::email("i@@remotos.com");
$this->assertFalse($email);
}
Se utiliza **assertFalse** en lugar de `assertTrue` porque se espera que el valor sea falso. Este tipo de pruebas garantiza que el código **no permita que información errónea pase sin ser detectada**.
Las pruebas automatizadas funcionan como un robot que verifica continuamente que cada componente opera según lo esperado [07:10]. Aplicar estas prácticas desde el inicio acerca los proyectos al mundo laboral, donde el código debe estar preparado y respaldado por *testing* antes de llegar a producción.
¿Ya has implementado pruebas unitarias en tus proyectos? Comparte tu experiencia y las dificultades que has encontrado al trabajar con PHPUnit.
