CursosEmpresasBlogLiveConfPrecios

Contenido del curso

Tomar examen

Creación de Proyectos PHP con Composer y PHPUnit

Resumen

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.