Laravel Livewire Aspectos claves para las pruebas de Integración o Unitarias
Índice de contenido
- Primeros pasos en las Pruebas en Laravel Livewire
- Primera prueba con Laravel Livewire 3
- Identificando la ruta
- Diferencia entre Feature y Unit Tests
- Pruebas de Feature vs. Pruebas Unitarias
- Prueba Base en Laravel Livewire 4
- ✅ Métodos de Aserción y Código 200
- Probar código 200
- Aserciones Específicas para Livewire
- Evaluar parámetros importantes
En Livewire, también podemos crear pruebas como hacemos las Pruebas Unitarias y de integración con Laravel base, su estructura es lo mismo una clase con extensión de test para que se para que se entienda que es una prueba extiende de TestCase:
tests/Feature/Blog/IndexTest.php
namespace Tests\Feature\Blog;
// use Illuminate\Foundation\Testing\RefreshDatabase;
// use Illuminate\Foundation\Testing\WithFaker;
// use PHPUnit\Framework\TestCase;
use Livewire\Livewire;
use Tests\TestCase;
use App\Livewire\Blog\Index;
use App\Models\Post;
class IndexTest extends TestCase
{
/**
* A basic feature test example.
*/
public function test_index(): void
{
$this
->get(route('web.index'))
->assertSeeLivewire(Index::class)
->assertStatus(200)
->assertSee("Post List")
// ->assertViewHas('posts', Post::paginate(15))
// ->assertViewIs('livewire.blog.index');
;
}
}
Es fundamental que en nuestros archivos de prueba aparezca la clase TestCase. Esto es lo que nos permite emplear el conjunto de métodos de tipo GET, POST, PUT y DELETE para realizar peticiones a las rutas de nuestra aplicación.
Y no estoy hablando del Funcionamiento de las peticiones para sincronizar propiedades y eventos en Laravel Livewire
Es importante aclarar que no me refiero al funcionamiento interno de Laravel Livewire para sincronizar propiedades, sino a probar los componentes de nuestra aplicación. Por defecto, ya sea que emplees Pest o PHPUnit, ambos tienen una clase llamada TestCase. Sin embargo, hay una diferencia crucial en las importaciones:
// use PHPUnit\Framework\TestCase;
use Tests\TestCase;Laravel incorpora estos métodos mediante un anidamiento de clases propio del framework. Gracias a esto, podemos evaluar componentes de múltiples formas. Por ejemplo, podemos usar aserciones para saber si un componente se está empleando internamente o si estamos usando correctamente los elementos de formulario, como el componente button de Livewire.
Comparado con Inertia, que es un poco más cerrado porque las pruebas suelen hacerse directamente en Vue, Livewire ofrece opciones más ricas para el testing desde el lado del servidor:
Livewire::test(Index::class)
->assertSee("Post List")
->assertViewHas('posts', Post::with('category')Primeros pasos en las Pruebas en Laravel Livewire
Vamos a iniciar creando nuestra prueba para el módulo de Blog, específicamente para el Index. Lo primero y más importante es ejecutar el comando de pruebas y verificar que todo pase correctamente:
$ php artisan testSi algo falla, debemos revisar qué está mal antes de continuar. Para este ejercicio, realizaré las pruebas mínimas necesarias. Podríamos probar distintos filtros, pero para no complicar el asunto al inicio, probaremos simplemente el acceso sin filtros aplicados para validar que se muestre el listado de publicaciones y categorías.
<?php
namespace Tests\Feature\Blog;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Illuminate\Foundation\Testing\WithFaker;
// use PHPUnit\Framework\TestCase;
use Tests\TestCase;
class IndexTest extends TestCase
{
public function test_example(): void
{
$response = $this->get('/');
$response->assertStatus(200);
}
}Primera prueba con Laravel Livewire 3
En una prueba rutinaria de Laravel básico, comenzaríamos verificando un status 200, el nombre de la ruta y los datos pasados a la vista. Sin embargo, al usar Livewire, la lógica cambia un poco.
Recomendación: Antes de empezar, duplica tu base de datos actual (copia y pega el archivo .sqlite o haz un respaldo) para no perder tus datos de prueba actuales. Más adelante configuraremos una base de datos específica para el entorno de testing.
Identificando la ruta
Debemos tener clara la ruta a probar (en este caso /blog). Si intentas acceder a una ruta inválida, obtendrás un error 404; si esperabas un 200 y recibes un 404, sabrás que el problema está en la definición de la ruta.
Aquí tienes el esquema inicial de la prueba:
<?php
namespace Tests\Feature\Blog;
use Tests\TestCase;
use Illuminate\Foundation\Testing\RefreshDatabase;
class IndexTest extends TestCase
{
public function test_example(): void
{
// Petición de tipo GET a la raíz o a /blog
$response = $this->get('/blog');
$response->assertStatus(200);
}
}Diferencia entre Feature y Unit Tests
Es vital heredar de Tests\TestCase. Si heredas accidentalmente de la clase interna de PHPUnit, el método $this->get() no existirá y la prueba fallará.
Estas son pruebas de tipo Feature y no de tipo Unit porque no estamos probando un módulo aislado o una función matemática simple; estamos probando el módulo completo del blog como un todo, incluyendo sus componentes y su respuesta HTTP.
$this->get(route('web.index'))->assertStatus(200);Al realizar pruebas, es fundamental indicar qué método HTTP vamos a emplear. En este ejemplo, realizaremos una petición de tipo GET. Para que esto funcione, es imprescindible que la clase de prueba herede de Tests\TestCase.
Es común confundirse con las importaciones, ya que existen dos clases con el mismo nombre. Fíjate en la diferencia:
- Incorrecto: PHPUnit\Framework\TestCase (Proviene del núcleo de PHPUnit).
- Correcto: Tests\TestCase (La clase propia de Laravel).
// use PHPUnit\Framework\TestCase;
use Tests\TestCase;Si utilizas la de PHPUnit por error, la prueba fallará al ejecutarse porque no encontrará los métodos necesarios para realizar peticiones. Aunque Tests\TestCase hereda lo básico de PHPUnit (o Pest, dependiendo de lo que estés usando), también agrega funcionalidades vitales de Laravel, como el manejo de peticiones HTTP.
Pruebas de Feature vs. Pruebas Unitarias
El uso de estas peticiones es imprescindible para nosotros, ya que nuestra meta es probar el módulo completo. No estamos evaluando funciones aisladas, sino nuestro módulo basado en componentes y la aplicación en su conjunto.
Por esta razón, estas son pruebas de tipo Feature (funcionales) y no de tipo Unit (unitarias). Es por ello que se encuentran organizadas en la carpeta de Feature, pues validamos la aplicación como un todo, específicamente en este caso el módulo de Blog.
Prueba Base en Laravel Livewire 4
Un aspecto fundamental es que podemos emplear rutas con nombre, aprovechando todas las bondades que esto nos trae (tal como vimos en el curso de Laravel básico).
Si decidimos cambiar la URL de blog por algo como /bloquecito, no tendremos que modificar nuestras pruebas, ya que están referenciadas por su nombre técnico, por ejemplo, web.index. Al usar la función route(), la prueba se adapta automáticamente al cambio:
public function test_index(): void {
$this->get(route('web.index'))
}Si lo hiciéramos de forma estática, como $this->get('blog'), cualquier cambio en la URL rompería el test devolviendo un error 404, obligándonos a actualizar el código manualmente en cada archivo de prueba.
public function test_index(): void {
$this->get('blog')
}✅ Métodos de Aserción y Código 200
Cuando probamos si una página se encontró correctamente, lo habitual es verificar el código de estado 200 (OK). Aunque en la documentación los métodos aparecen en orden alfabético y no siempre clasificados por utilidad, Laravel nos ofrece variantes muy potentes para evaluar:
- Redirecciones.
- Contenido HTML.
- Si el usuario está autorizado o autenticado.
Lo mejor es que no tenemos que navegar manualmente por la respuesta para extraer valores; Laravel lo hace por nosotros de forma automática mediante sus métodos de aserción.
Si estamos empleando la clase TestCase de Laravel y queremos validar específicamente qué vista está cargando el componente, podemos usar el método assertViewIs:
public function test_index_view(): void {
$response = $this->get(route('web.index'));
$response->assertStatus(200);
// Validamos que la vista sea la correcta
$response->assertViewIs('web.index');
}Esto nos permite asegurar que, más allá de que la página cargue, el usuario esté viendo exactamente la interfaz que le corresponde.
Probar código 200
Para verificar si la página se encontró correctamente, Laravel nos ofrece diversos métodos. Aunque en la documentación aparecen por orden alfabético y no siempre clasificados por utilidad, el más común es el que valida el estado "OK", que es equivalente al status 200.
Además de los estados básicos, existen variantes para probar redirecciones o contenido HTML. En el fondo, estas herramientas son condicionales, pero no son genéricos que solo evalúan valores exactos. También pueden aplicar lógica compleja, como verificar si un usuario está autorizado o autenticado. Lo mejor es que Laravel hace todo esto "de gratis" y automáticamente a través de sus métodos de aserción, sin necesidad de que nosotros naveguemos manualmente por la respuesta para extraer datos.
Aserciones Específicas para Livewire
Si estamos empleando la clase TestCase de Laravel y queremos validar qué vista se está cargando, utilizamos el método assertViewIs. Aquí podemos encadenar múltiples pruebas para verificar el comportamiento de nuestro componente:
Livewire::test(Index::class)
->assertSee("Post List")
->assertViewHas('posts', Post::with('category')
->where('posted', 'yes')->paginate(15))
->assertViewIs('livewire.blog.index')A veces, necesitamos ver exactamente qué contiene la respuesta o qué datos están llegando a la vista. Para ello, podemos pasar un callback al método assertViewHas y realizar un volcado de datos con dd():
->assertViewHas('posts', function ($posts){
dd(Post::paginate(15));
dd($posts);
})Sin embargo, hay que tener cuidado: al hacer un dd() de la página completa, el contenido suele ser tan extenso que la consola lo corta, lo que puede dificultar la lectura. Aunque en esta clase el propósito es experimentar y ver qué herramientas tenemos disponibles, este método es muy útil para depurar de forma puntual si los datos de la colección coinciden con lo esperado.
Evaluar parámetros importantes
También, podemos utilizar Livewire::test() para evaluar un componente de Laravel Livewire:
***
use Livewire\Livewire;
class IndexTest extends TestCase {
public function test_index(): void
{
$this
->get(route('web.index'))
***
;
Livewire::test(Index::class);
}
}Y desde aquí, podemos emplear los métodos se aserción que no pudimos emplear antes:
tests/Feature/Blog/IndexTest.php
***
use Livewire\Livewire;
class IndexTest extends TestCase {
public function test_index(): void
{
$this
->get(route('web.index'))
***
;
Livewire::test(Index::class)
->assertSee("Post List")
->assertViewHas('posts', Post::with('category')
->where('posted', 'yes')->paginate(15))
->assertViewIs('livewire.blog.index')
;
}
}
Acepto recibir anuncios de interes sobre este Blog.
Daremos una introducción a las pruebas específicas para Laravel Livewire presentando sus métodos de aserción principales.