El pasado 24 de Enero se lanzó laravel 5.4 y con ello se introdujeron algunos cambios en el sistema de Testing de Laravel. El más significativo de ellos, sin duda, es la aparición de Laravel Dusk. Este nuevo componente está diseñado para realizar pruebas automatizadas en Laravel desde la perspectiva de un usuario (incluso usando Javascript), como pudimos ver en esta publicación dedicado a ello.

Laravel 5.4 trae consigo una nueva capa de tests HTTP que sustituye la mayoría de helpers disponibles en 5.3. La manera más simple de que todo vuelva a funcionar tal cual estaba antes es instalar el Browser Kit Testing y hacer que nuestro TestCase base extienda de éste.

<?php

namespace Tests;

use Laravel\BrowserKitTesting\TestCase as BaseTestCase;

abstract class TestCase extends BaseTestCase
{
    use CreatesApplication;
}

Una vez que todo vuelve al «verde», tenemos la opción de migrar todos los helpers que no funcionan y adaptarlos al nuevo TestCase de Laravel 5.4. Para ello vuelve a extender del original:

<?php

namespace Tests;

use Illuminate\Foundation\Testing\TestCase as BaseTestCase;

abstract class TestCase extends BaseTestCase
{
    use CreatesApplication;
}

La principal novedad, y en la que se basa nuestra «refactorización», es que los helpers orientados a interactuar con el navegador (visit, press, see, etc..) ahoras son métodos propios de Dusk, por lo que éstas pruebas funcionales pueden ser trasladadas a este paquete, para así centrarnos en probar unitariamente nuestras clases y también en probar la integración con el API a través de esta nueva capa HTTP que nos trae Laravel 5.4.

Otra característica importante es que ahora las llamadas al API devuelven un objeto Response, el cual tiene sus propios métodos de comprobación.

Veamos un ejemplo sencillo. Supongamos que nuestra prueba es algo tal que así:

public function testBasicTest()
{
    $this->visit('/')
         ->see('Juan'); //Usuario que devuelve el backend
}

Lo que haríamos en Laravel 5.4 sería probar que al hacer un request de tipo GET al home, podemos ver en la vista devuelta al usuario que nos envía el backend:

public function testBasicTest()
{
     $response = $this->get('/');

     $response->assertStatus(200);
     $response->assertViewHas('user', 'Juan');
}

Así estaríamos probando el funcionamiento de nuestro API, en la mayoría de los casos suficiente para comprobar que todo está correcto. Si aún así queremos probar la experiencia del usuario en el navegador podemos acompañar nuestras pruebas con otras en Dusk, las cuales solo ejecutaremos cuando creamos conveniente. (Son más lentas).

Listado con las comprobaciones disponibles en el objeto response:

$response->assertStatus($code); 	
$response->assertRedirect($uri); 	
$response->assertHeader($headerName, $value = null); 	
$response->assertCookie($cookieName, $value = null); 	
$response->assertPlainCookie($cookieName, $value = null); 	
$response->assertSessionHas($key, $value = null); 	
$response->assertSessionMissing($key); 	
$response->assertJson(array $data); 	
$response->assertJsonFragment(array $data); 	
$response->assertExactJson(array $data); 	
$response->assertJsonStructure(array $structure); 	
$response->assertViewHas($key, $value = null);

El resto de métodos de testing dispobibles en el TestCase son básicamente los mismos, exceptuando alguno importante como seeInDatabase  que ahora es assertDatabaseHas y su contrario dontSeeInDatabase que ahora es assertDatabaseMissing.

Aplicando estos cambios a tu Suite de Pruebas deberías volver al «verde» sin problemas. Sientente libre de dejarnos un comentario si estás teniendo algún problema.

Material relacionado

Regístrate hoy en Styde y obtén acceso a todo nuestro contenido.