Haciendo Pruebas Automatizadas en Laravel [PARTE I]

Hoy en día (y siempre) es indispensable realizar pruebas automatizadas en nuestros proyectos, ya que nos brinda una red de respaldo a la hora de agregar, modificar y refactorizar nuestro sistema.

Pero mucha gente no sabe exactamente por donde empezar, como probar, que probar y hasta donde probar. Así que, comenzare una guía para responder estas preguntas y hacer lo posible para plantarte la semilla de las pruebas automatizadas ✊.

Poniéndonos en contexto

En el grupo de Facebook, Hablemos de Laravel, realice una encuesta para saber cuantas personas realizaban pruebas automatizadas en sus proyectos de Laravel y cuantas no. Mas que nada para saber porque no lo estaban haciendo. Y estos fueron los resultados.

Así que, comencemos con la opción que la mayoría de las personas votaron, ¿por donde empiezo?

¿Por que realizar pruebas automatizadas?

Seguramente, les ha pasado que les dan un proyecto y les piden hacer modificaciones o agregar una nueva funcionalidad. Y es un sistema tan grande que, al agregar la modificación, generan un bug en otra parte del sistema. Y tal vez, se enteran cuando ya esta en producción y es peor si es el cliente el que les avisa sobre el bug.

Si hacemos una comparación, salir a producción con un sistema que no tiene pruebas es como un equilibrista que hace su primera demostración sin haber practicado antes.

Este equilibrista tiene muchas chances de no contarla…💀

Pero, si desarrollamos con una red de cobertura, podremos caernos todas las veces que queramos. Total, seguiremos vivos para corregir el código y seguir programando. Así nos garantizamos que el código que instalamos en producción ha pasado por varias pruebas.

Pero ahora bien, la pregunta es ¿por donde empiezo a probar? así que intentemos responder a esta pregunta.

¿Por donde empezar a probar?

Si tenemos un sistema heredado (todo sistema que no tiene pruebas automatizadas se lo considera sistema heredado), lo que recomiendo es empezar con pruebas funcionales.

¿Qué son las pruebas funcionales? Son las pruebas que tardan mas tiempo en ejecutarse pero tienen una gran cobertura.

En cambio, si estamos comenzando con un nuevo sistema o un nuevo requerimiento, lo mejor es hacer pruebas unitarias.

¿Qué son las pruebas unitarias? Son pruebas que atacan a una parte especifica del sistema (un método normalmente) y son las pruebas que más rápido se ejecutan.

Poniéndonos en marcha

Por la encuesta que realiza en Hablemos de Laravel, supongo que la mayoría de las personas no saben por donde comenzar con un sistema heredado. Así que arranquemos con las pruebas funcionales.

Para demostrar cómo comenzar con las pruebas, probaré el componente de autenticación de Laravel.

Si ustedes utilizan la autenticación por defecto de Laravel, sería un error realizar pruebas sobre esto. Ya que es regla no realizar pruebas sobre sistemas que confiamos. Con ese criterio, entonces deberíamos probar todos los componentes de Laravel y ahí es cuando nos quita tiempo de desarrollo.

Pero, para los propósitos de esta guía, es perfecto para comenzar a probar porque podemos fantasear que es un código heredado y además tiene mucha lógica como múltiples tipos de solicitudes, re direccionamientos, validación de datos, interacción con la base de datos y autenticación de usuario.

Esto nos permitirá aprender de manera incremental más sobre cómo probar aplicaciones Laravel. Desde aquí puedes aplicar estas prácticas a tus propias aplicaciones.

Instalación

Para comenzar, instalaré una nueva aplicación Laravel (5.8) usando el instalador Laravel :

laravel new start-testing-laravel

Ingresaré al directorio del proyecto Laravel y ejecutaré make:auth para generar todos los componentes de autenticación :

cd start-testing-laravel/
php artisan make:auth

El último comando nos genera todo lo relacionado a la autenticación de usuario (registración, inicio de sesión, recuperación de contraseña, etc.). Lo cual es genial, ya que quiero centrarme en escribir pruebas.

Ejecutando pruebas

Laravel incluye un entorno de pruebas pre-configurado y algunos tests de ejemplo. En el fondo utiliza el framework de testing PHPUnit .

Para ejecutar las pruebas de ejemplo, puedo ejecutar el siguiente comando en la consola:

vendor/bin/phpunit

Y obtendremos un resultado como este donde todo es verde.

Escribiendo la primera prueba

Para la primera prueba, quiero que empieces a ganar impulso con las pruebas y empieces a sentir los beneficios. Por eso, comenzaremos probando algo simple. 

Empezaremos a escribir una prueba para la página de inicio de sesión y seguiremos a partir de allí. Para crear una nueva prueba haremos uso del comando artisan make:test:

php artisan make:test Http/Controllers/Auth/LoginControllerTest

Yo suelo organizar mis test respetando la jerarquía de carpetas para luego asociar rápidamente un controlador (por ejemplo) con su test.

Repasemos rápidamente el comando. Primero, la ruta refleja la de mi carpeta app. En segundo lugar, se debe agregar el sufijo Test en el nombre del controlador. PHPUnit ejecutará automáticamente cualquier archivo PHP dentro de las carpetas Feature o Unit con el sufijo Test. Si bien esto es configurable, es una convención.

Este comando genera la siguiente clase:

<?php

namespace Tests\Feature\Http\Controllers\Auth;

use Tests\TestCase;
use Illuminate\Foundation\Testing\WithFaker;
use Illuminate\Foundation\Testing\RefreshDatabase;

class LoginControllerTest extends TestCase
{
    /**
     * A basic feature test example.
     *
     * @return void
     */
    public function testExample()
    {
        $response = $this->get('/');

        $response->assertStatus(200);
    }
}

Repasando el código generado, vemos que nuestra clase extiende de la clase TestCase. Esta se encuentra en la carpeta tests y es donde podemos agregar código para compartir en todas las pruebas. A su vez, Laravel utiliza la clase TestCase para brindarnos métodos de ayuda y afirmaciones que podemos usar durante las pruebas.

En segundo lugar, creó un caso de prueba. Cada método debe representar un caso. Por convención, PHPUnit ejecutará cualquier función public con el prefijo test. También podemos usar la anotación  @test para marcar un caso de prueba. Creo que definir las pruebas por medio de la anotación y escribiendo el nombre del método en Snake Case es más común entre la comunidad de Laravel.

Seguiré esta convención y ajustaré el nombre de la prueba para transmitir lo que nuestra prueba intenta verificar. Y esto último es algo muy muy importante. Nuestra prueba automatizada deben ser lo mas descriptivos posible, si te lleva 65 o 75 caracteres describir el caso de prueba, no lo dudes y hacelo!

-    /**
-     * A basic feature test example.
-     *
-     * @return void
-     */
+    /** @test */
-    public function testExample()
+    public function login_displays_the_login_form()

Este nombre puede parecer redundante. Pero a medida que tu batería de pruebas crezca, te ayudará bastante.

Averiguar qué probar

Ahora que creamos el caso de prueba, debemos escribir la prueba. Es importante centrarse en el comportamiento que esta prueba pretende verificar. En este caso, quiero asegurarme de que cuando visito /login, se muestre el formulario de inicio de sesión.

Resumiendo a un lenguaje mas técnico, esto significa que:

Cuando envío una solicitud GET a la ruta login, 
entonces debería devolver la vista auth.login.

En la clase que generamos, ya vemos como generar una solicitud HTTP de tipo get. Así que nada mas debemos cambiar la ruta y es muy importante que siempre utilicemos los helpers route() o action() (en ese orden de prioridad). Ya que, si la ruta cambia su url o controller, nuestra prueba seguira funcionando.

También vemos que podemos hacer afirmaciones sobre la respuesta. Si examinamos la clase TestResponse, podremos ver todas las aserciones disponibles. Para este caso nos sirve la afirmación  assertViewIs.

Nuestra prueba quedará de la siguiente forma:

/** @test */
public function login_displays_the_login_form()
{
    $response = $this->get(route('login'));

    $response->assertStatus(200);
    $response->assertViewIs('auth.login');
}

Ahora volvemos a ejecutar las pruebas, pero esta vez limitado a LoginControllerTest:

vendor/bin/phpunit tests/Feature/Http/Controllers/Auth/LoginControllerTest.php

La prueba pasa y todo es verde 🌈.

Escribiste tu primera prueba de Laravel 👏! Y si, puede que esta prueba no te parezca tan valiosa. Pero la idea de este artículo es que comiences a tomar confianza en las pruebas y veas que se escriben fácil y rápido.

Deja que la pequeña semillita de las pruebas crezca en ti y pasemos a escribir la próxima prueba que será mejor que esta 😉✊.

Escribiendo la segunda prueba

Ahora que tenemos nuestra primera prueba, abordemos algo un poco más complejo. Todavía no estamos listos para hacer pruebas contra base de datos. Pero tal vez podamos probar algún otro tipo de comportamiento relacionado con la realización de solicitudes básicas.

Siguiendo con el formulario de inicio de sesión, hagamos una solicitud que envíe los datos del formulario e intente iniciar sesión. Dado que aún no estamos listos para integrarnos con la base de datos, podemos probar que el inicio de sesión respondió con un error de inicio de sesión.

Traduzcamos este objetivo una vez más al lenguaje técnico:

Cuando realizo una solicitud de tupo POST a la URL login, 
dado que he enviado credenciales no válidas, 
me redirigen nuevamente a la página de inicio de sesión 
y recibo un error de validación.

Primero, escribimos un nuevo caso de prueba en la clase:

/** @test */
public function login_displays_validation_errors()
{
    // ...
}

Ahora escribo la prueba y paso a comentarles que hice en cada caso:

/** @test */
public function login_displays_validation_errors()
{
    $response = $this->post(route('login'), []);

    $response->assertStatus(302);
    $response->assertSessionHasErrors('email');
}

Por otro lado, también quiero probar que se produzca una redirección cuando se genera un error de validación. Por lo tanto, cambio el código de assertStatus a 302 para verificar la redirección.

Ahora necesito hacer valer los errores de validación. Sé que Laravel pone errores de validación en la sesión. Echando otro vistazo a las afirmaciones de respuesta que encontramos assertSessionHasErrors(). Puedo usar esto para verificar que la sesión contiene errores de validación para ciertos campos de formulario, por ejemplo, para el email.

Las pruebas son sobre la confianza

En este momento, tal vez estés pensado que la ultima prueba que escribimos está un poco incompleta. Por ejemplo, no pasé ningún dato, no valide el mensaje de validación exacto, no escribí pruebas automatizadas para otras combinaciones de datos no válidos. etc.

Al comenzar con las pruebas, puede inclinarse a escribir pruebas automatizadas para cada ruta de código. Esta bien. Especialmente si te ayuda a ganar impulso. Pero, al final de cuentas, las pruebas se tratan de confianza, no de cobertura.

Raramente se prueban todas las rutas posibles. Como dije anteriormente, probar las rutas como lo estamos haciendo, entran en el grupo de pruebas funcionales y estas son las que mas tardan en ejecutarse.

Lo que queremos es que nuestras pruebas se ejecuten en un tiempo considerable porque el próximo paso es agregar CI (integración continua) 😉. Además, queremos que cubran lo necesario para darnos la confianza de que el código se está comportando como se esperaba.

Probar de más es ineficiente e ineficaz, nos quita tiempo y no nos brindan mayor confianza.

Este único test me da la suficiente confianza para enviar datos no válidos para que login se comporte como esperaba. Especialmente porque, en la autenticación, Laravel solo devuelve un error de validación para el campo email. Por lo tanto, cualquier combinación de datos no válidos realizaría las mismas afirmaciones.

Además, acá es donde cobran más sentido utilizar FormRequest. Los FormRequest se prueban con test unitarios, son muy fáciles de probar y nos brinda una mayor cobertura sobre cada campo a validar. Lo veremos en un próximo artículo.

Haciendo pruebas contra base de datos: Model Factory

Estamos listos para probar el inicio de sesión en la aplicación. Pero para hacerlo, necesitamos tener un usuario en la base de datos que coincida con los datos enviados a /login.

Esto nos lleva al siguiente paso incremental de esta guía de pruebas en Laravel. Sabemos que para el acceso a base de datos, Laravel utiliza modelos que extienden de Eloquent.

Entonces, ¿cómo probamos Eloquent? La respuesta es que no lo hacemos. En cambio, colocamos datos en la base de datos y permitimos que Laravel se comporte como lo haría normalmente.

---

NOTA: Recordemos que estamos en los test funcionales y en este tipo de pruebas si esta permitido ir a base de datos, ya veremos en los test unitarios que ir a base de datos, esta prohibido.

---

Esto puede sonar bastante difícil, pero Laravel nos brinda las factory para hacer que esto sea fácil de configurar con unos simples pasos.

Primero, podemos crear una factory para nuestro modelo. Esto nos permite generar un modelo y rellenar previamente sus datos rápidamente. Estas factories se encuentran en la carpeta database/factories.

Laravel viene con una UserFactorycaja lista para usar:

<?php

/** @var \Illuminate\Database\Eloquent\Factory $factory */

use App\User;
use Illuminate\Support\Str;
use Faker\Generator as Faker;

$factory->define(User::class, function (Faker $faker) {
    return [
        'name' => $faker->name,
        'email' => $faker->unique()->safeEmail,
        'email_verified_at' => now(),
        'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password
        'remember_token' => Str::random(10),
    ];
});

Una vez que tenemos nuestra factory lista, podemos usar el helper factory()en cualquiera de nuestras pruebas para crear datos del modelo y persistirlos en la base de datos.

Veamos como quedaría la prueba automatizada para el inicio de sesión exitoso, creando un usuario valido previamente. Primero creo un usuario en la base de datos:

/** @test */
public function login_authenticates_and_redirects_user()
{
    $user = factory(User::class)->create();

    // ...
}

Antes de seguir, necesito hacer algunas configuraciones para usar la base de datos.

Primero, vamos a configurar una base de datos en memoria como SQLite. Esto se hace para evitar conflictos la base de datos de desarrollo y, además, para que la prueba se ejecute más rápido.

No necesitas tener conocimientos de SQLite.

Abrirmos el archivo phpunit.xml de nuestro proyecto proyecto y le agregamos las dos ultimas lineas que figuran en la siguiente imagen:

<php>
     <server name="APP_ENV" value="testing"/>
     <server name="BCRYPT_ROUNDS" value="4"/>
     <server name="CACHE_DRIVER" value="array"/>
     <server name="MAIL_DRIVER" value="array"/>
     <server name="QUEUE_CONNECTION" value="sync"/>
     <server name="SESSION_DRIVER" value="array"/>
+    <server name="DB_CONNECTION" value="sqlite"/>
+    <server name="DB_DATABASE" value=":memory:"/>
</php>

También necesito decirle a esta prueba que use la base de datos. De lo contrario, cuando vaya a ejecutar la prueba recibiré varios errores de base de datos similares a este:

Esto se debe a que la base de datos no esta creada como tal. Todo lo que necesitamos hacer es agregar el trait RefreshDatabase a la clase de test.

class LoginControllerTest extends TestCase
{
+    use RefreshDatabase;

Este trait ejecutará las migraciones de la base de datos de la aplicación y, entre cada caso de prueba, actualizará la base de datos a su estado original.

Entonces, para cualquier caso de prueba, solo tenemos que crear los datos necesarios para obtener el comportamiento que esperamos.

Volviendo al caso de prueba de inicio de sesión, termina pareciéndose bastante al caso de prueba de validación. Utilizaré una nueva afirmación para verificar que el usuario autenticado es el mismo que el usuario que creamos con factory(). Nuestro caso de prueba finalmente quedaría así:

/** @test */
public function login_authenticates_and_redirects_user()
{
    $user = factory(User::class)->create();

    $response = $this->post(route('login'), [
        'email' => $user->email,
        'password' => 'password'
    ]);

    $response->assertRedirect(route('home'));
    $this->assertAuthenticatedAs($user);
}

Hacer aserciones de bases de datos

Por un lado podemos crear datos para que nuestras pruebas automatizadas los use. Pero por otro lado, debemos hacer las afirmaciones que los datos se crearon correctamente en la base de datos cuando es la aplicación la que los crea.

Veamos con un ejemplo a lo que me refiero. Escribamos un caso de prueba para el registro de usuarios. Me enfocaré en el camino feliz. El camino feliz es aquella prueba que no dará ningún error. En el caso del registro de usuarios, su camino feliz cuando se crea un nuevo usuario con los datos de registro correctamente.

Vamos a aplicar lo que ya vimos hasta ahora para comenzar a escribir la mayor parte de este caso de prueba. Enviaremos una solicitud POST a la registración de usuario, con datos válidos y confirmaremos que la redirección sera a la ruta home.

/** @test */
public function register_creates_and_authenticates_a_user()
{
    $response = $this->post(route('register'), [
        'name' => 'JMac',
        'email' => 'jmac@example.com',
        'password' => '123456',
        'password_confirmation' => '123456',
    ]);

    $response->assertRedirect(route('home'));

    // ...
}

Si bien esta prueba pasaría, no estaríamos verificando completamente el comportamiento esperado. Hay dos aspectos más que no hemos cubierto.

Primero, no estamos cubriendo que realmente se crea el usuario en la base de datos con los datos que enviamos a la solicitud. Para ello podemos utilizar el método assertDatabaseHas. El método acepta los siguientes parámetros.

assertDatabaseHas(string $table, array $data, string $connection = null)

Para este caso de prueba, quiero verificar que la tabla users contenga un registro que coincida con el  namey email que hemos enviado en los datos de la solicitud.

Para hacerlo, agregaré la siguiente afirmación.

$this->assertDatabaseHas('users', [
    'name' => 'JMac',
    'email' => 'jmac@example.com'
]);

Cómo puedes ver todos nuestros test son simples, no tienen mucho código, ni cosas locas y no tienen más de 2 o 3 aserciones. Así es como debes crear tus pruebas automatizadas.

Utilizando datos de prueba con Faker

En los ejemplos anteriores utilice datos creados por mi, esta es la mejor manera. Pero, a modo informativo, quería comentarles que tenemos disponible una herramienta que genera datos de prueba aleatorios por nosotros.

Laravel tiene integrado un paquete llamado Faker. Faker nos brinda la posibilidad de generar todo tipo de datos.

Puedo utilizar la propiedad faker agregando el trait WithFaker proporcionado por Laravel, para generar datos.

class LoginControllerTest extends TestCase
{
-    use RefreshDatabase;
+    use RefreshDatabase, WithFaker;

Ahora puedo actualizar el caso de prueba para variar los datos de la solicitud con Faker.

/** @test */
public function register_creates_and_authenticates_a_user()
{
    $name = $this->faker->name;
    $email = $this->faker->safeEmail;
    $password = $this->faker->password(8);

    $response = $this->post('register', [
        'name' => $name,
        'email' => $email,
        'password' => $password,
        'password_confirmation' => $password,
    ]);

    $response->assertRedirect(route('home'));

    $this->assertDatabaseHas('users', [
        'name' => $name,
        'email' => $email
    ]);
}

Pero, como dije anteriormente, no es aconsejable utilizar datos variables en las pruebas. Siempre es mejor establecer los valores de pruebas nosotros mismos. Ya que tenemos mayor control y los datos variables pueden llegar a ser un problema en nuestros tests.

Autenticar usuarios para nuestras pruebas

Todo lo que vimos hasta ahora cubre una buena parte para que comiences a probar tus aplicaciones Laravel. Pero hay una cosita más que necesitarás saber para hacer ciertos casos de prueba: poder autenticar un usuario para probar solicitudes que lo requieren.

Para hacerlo, simplemente utilizamos el método actingAs() antes de la llamada a la solicitud y le pasamos un usuario.

Vamos a hacer una prueba automatizada simple para la ruta home que está protegida por el middleware auth.

<?php
namespace Tests\Feature\Http\Controllers;
use App\User;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;
class HomeControllerTest extends TestCase
{
    use RefreshDatabase;
    /** @test */
    public function index_returns_a_view()
    {
        $user = factory(User::class)->create();

        $response = $this->actingAs($user)->get(route('home'));

        $response->assertStatus(200);
    }
}

De esta forma, autenticamos un usuario para poder probar rutas o códigos que requieren un usuario autenticado.

Algunas convenciones

Algunas de las convenciones que ya vimos fueron escribir los nombres de los test lo mas descriptivos posibles, utilizando Snake Case y anotación. Otra de la convención que quería comentar es que las pruebas automatizadas deben tener tres saltos de linea únicamente, en lo posible.

Si miran el último test que escribimos podemos ver que primero van los datos que utilizaremos en nuestro SUT (System Under Test, lo que vamos a probar), hacemos un salto de linea y luego escribimos el SUT, que es el código que vamos a atacar. Hacemos un salto de linea más y a continuación escribimos las aserciones o afirmaciones.

De esta forma, mantenemos un orden, una legibilidad y nos entenderemos con el resto del equipo.

Conclusión

Cómo pudimos ver, el secreto es mantener tus test simples, con poco código y nomás de 2 o 3 aserciones. De esta forma serán muy fáciles de entender que se está probando y nos será fácil modificarlos en el futuro (si, los test también se mantienen!).

Te invito a que escojas el controlador más simple que tengas en alguno de tus proyecto y le apliques pruebas automatizadas. Y en la próxima parte de esta guía comenzaremos con las pruebas unitarias, convenciones y buenas practicas para que aprendas a hacer pruebas de calidad en tus proyectos de Laravel.

Espero que te haya gustado. Cualquier duda, la puedes dejar en los comentarios que con gusto las responderé. Nos leemos en la próxima 😉🤙.

Ya esta disponible la segunda parte de esta guía: https://www.laraveltip.com/haciendo-pruebas-automatizadas-en-laravel-unit-test/