Probar su aplicación Symfony

1. Las pruebas: un elemento esencial para la calidad del software

Las pruebas de software garantizan la robustez y la calidad de una aplicación partiendo de un principio simple: cuanto antes se identifique un problema, más barato será arreglarlo.

Si una aplicación no dispone de un conjunto de pruebas, es muy probable que, a medida que evoluciona, a medida que se agregan correcciones de errores y nuevas funcionalidades, aparezcan nuevos errores en funcionalidades ya existentes. Esto se denomina «regresión» y las pruebas de software permiten garantizar la no regresión de la aplicación.

Más allá de este concepto de no regresión, es esencial poder validar todas las etapas de construcción de una aplicación, desde las primeras líneas de código hasta el ensamblado de funcionalidades en clases y componentes y, para terminar, poder probar la interfaz de usuario de la aplicación.

Durante todas estas fases de construcción de software, se implementan diferentes familias (o categorías) de pruebas.

2. Las diferentes categorías de pruebas

En un proceso de construcción de software, van a entrar en acción varias categorías de pruebas, cada una en una etapa más o menos avanzada del proyecto. Es erróneo pensar que solo son importantes las pruebas que se ejecutan al final del desarrollo...

1. Configuración de pruebas

Para poder configurar las pruebas en su aplicación Symfony, primero es necesario instalar PHPUnit. PHPUnit se instala a través de una recipe Flex utilizando el siguiente comando:

composer require --dev phpunit/phpunit symfony/test-pack 

Una vez completada la instalación, debería poder invocar PHPUnit con el siguiente comando, pasado desde su directorio de proyecto:

php ./vendor/bin/phpunit 

De forma predeterminada, este comando ejecuta todas las pruebas presentes en el directorio tests/. Aquí, no se han ejecutado pruebas, como indica la salida del comando.

2. Regla de escritura de las pruebas

Todas las pruebas unitarias de sus funcionalidades se deben almacenar en el directorio tests/ de su aplicación Symfony. De hecho, este directorio es el asociado con el entorno de prueba del framework que, por lo tanto, se puede basar en una configuración específica definida en un archivo .env.test en la raíz de su proyecto. Este archivo podría contener una dirección URL para conectarse a una base de datos dedicada a las pruebas.

Considere el siguiente ejemplo de clase:

namespace App\Model;    
    
class Usuario    
{    
   private $apellido;    
   private $nombre;    
   
   public...

1. Diferencia respecto a las pruebas unitarias y de integración

A diferencia de las pruebas unitarias y de integración, que están destinadas a probar los resultados de las invocaciones de los diferentes métodos en sus clases, las pruebas funcionales verifican los comportamientos de la aplicación.

La prueba funcional más común es la prueba de sus controladores. Dado que sus acciones dependen de un determinado contexto HTTP, no se trata de verificar directamente el retorno de los métodos de sus controladores, sino de simular peticiones HTTP y analizar las respuestas devueltas.

Claramente, las pruebas funcionales reproducen las condiciones reales de uso de su aplicación. Desde un determinado punto de vista, se pueden considerar más complejas que las pruebas unitarias, en el sentido de que requieren la creación de un determinado contexto.

2. Probar una acción

Introduzcamos las pruebas funcionales a través de una acción básica:

namespace App\Controller;  
    
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController; 
use Symfony\Component\HttpFoundation\Request;  
use Symfony\Component\HttpFoundation\Response;  
use Symfony\Component\Routing\Annotation\Route;  
    
class DefaultController extends AbstractController  
{    
   /**  
    * @Route("/hola/{nombre}")    
    */  
   public function hola($nombre)    
   {  
       return new Response('¡Hola, ' . $nombre.'!');  
   }  
} 

Para esta acción, sería legítimo pensar en la siguiente clase de pruebas:

namespace App\Tests\Controller;  
  
use App\Controller\DefaultController;  
  
class DefaultControllerTest extends \PHPUnit\Framework\TestCase 
{    
   public function testHola()  
   {    
       $controlador = new DefaultController;  
  
       $respuesta...