Automatizar pruebas en Laravel te permite reemplazar la revisión manual en Postman o el navegador por un código que valida tus endpoints, documenta el comportamiento esperado y detecta errores en segundos. Esta guía práctica está pensada para desarrolladores backend que ya construyen APIs con Laravel y quieren incorporar testing automatizado a su flujo diario.

La idea central es simple: en lugar de visitar cada ruta manualmente y revisar la respuesta, escribes un test que hace ese trabajo por ti, una y otra vez, sin equivocarse.

¿Qué hace el comando PHP Artisan test en Laravel?

Laravel trae testing integrado desde la instalación. Al ejecutar php artisan test en la terminal, el framework corre todos los archivos de prueba que tengas definidos y te muestra cuáles pasan y cuáles fallan.

Por defecto, encuentras un archivo de ejemplo dentro de la carpeta de tests, tanto en Feature como en Unit. Puedes eliminarlos para empezar a trabajar con tus propias pruebas.

¿Para qué sirven los tests automatizados? Sirven para validar que tu código funciona como esperas sin tener que revisarlo manualmente cada vez. Además, funcionan como documentación viva del comportamiento de tu API.

Para crear un nuevo test, usas el comando de generación: php artisan make:test CategoryTest. Esto crea un archivo donde escribirás las pruebas específicas para el controlador de categorías [02:00].

¿Cómo escribir un test para el método index de un controlador?

Antes de escribir el test, piensa en el flujo manual: inicias sesión, generas un token, visitas la ruta con ese token en el header de autorización y revisas la respuesta. Ese mismo flujo se replica en código.

Lo primero es preparar la base de datos con datos de prueba. Para eso necesitas importar varias clases clave:

• El trait RefreshDatabase para reiniciar la base entre pruebas.
• La clase Response desde Symfony\Component\HttpFoundation para manejar códigos HTTP.
• El modelo Category y el modelo User.

El usuario es indispensable porque tu API requiere autenticación. Para iniciar sesión en el test usas la tecnología de Laravel Sanctum, indicando el guard y el modelo correspondiente.

¿Cómo simular un usuario autenticado en un test?

La secuencia es directa. Creas un usuario con un factory, le dices al test que actúe como ese usuario y luego generas las categorías que necesitas para validar la respuesta:

php $user = User::factory()->create(); Sanctum::actingAs($user); $categories = Category::factory()->count(2)->create();

Después visitas la ruta con getJson('/api/categories') porque trabajas con un API que devuelve JSON.

¿Qué afirmaciones debe incluir un test de listado?

El test debe verificar dos cosas mínimas. Primero, que la cantidad de elementos devueltos coincida con los creados. Si insertaste dos categorías, esperas dos en el key data. Segundo, que la estructura del JSON sea la correcta:

php $response->assertJsonCount(2, 'data'); $response->assertJsonStructure([ 'data' => [ ['id', 'type', 'attributes' => ['name']] ] ]);

Esto es exactamente lo que harías en Postman: revisar que la respuesta tenga el número correcto de registros y los campos esperados [05:30].

¿Cómo probar el método show con un recurso específico?

El test del método show sigue la misma lógica, pero con una sola categoría. Creas el usuario, autenticas, generas una categoría y visitas la ruta apuntando al ID de ese registro:

php $category = Category::factory()->create(); $response = $this->getJson('/api/categories/' . $category->id); $response->assertStatus(Response::HTTP_OK);

El Response::HTTP_OK representa el código 200, y por eso importamos la clase de respuestas HTTP. La estructura esperada ya no es un array de elementos, sino un único objeto, porque visitas un solo recurso.

¿Qué pasa si cambio el conteo esperado a 3 cuando creé 2 registros? El test falla y la terminal te muestra exactamente qué afirmación no se cumplió. Ese mensaje de error es la guía para corregir tu código o tu expectativa.

Al ejecutar php artisan test después de escribir ambas pruebas, la terminal te confirma que el index y el show de categorías funcionan correctamente.

¿Por qué necesitas una base de datos separada para testing?

Aquí viene un detalle crítico. Si corres los tests con RefreshDatabase, Laravel borra todos los registros de tu base de datos de desarrollo. Eso no debería pasar nunca.

Todo proyecto serio trabaja con tres bases de datos:

• La base de producción, con datos reales de usuarios.
• La base de desarrollo, donde construyes y experimentas.
• La base de pruebas, exclusiva para los tests automatizados.

La solución está en el archivo phpunit.xml. Ahí descomentas las líneas que configuran SQLite en memoria como base de datos de prueba. Le dices a PHPUnit: cuando corras tests, no uses mi base principal, usa una base temporal en memoria.

Después restauras tu base de desarrollo con php artisan migrate:refresh --seed y todos tus datos vuelven: 12 categorías, 100 recetas, toda la configuración inicial. Al ejecutar los tests de nuevo, pasan con éxito y tu base de desarrollo queda intacta [12:40].

¿Ya estás aplicando testing automatizado en tus proyectos Laravel? Cuéntame en los comentarios qué controladores fueron los primeros que decidiste cubrir con pruebas.