Automatiza pruebas de API en Laravel

Curso de Estándares y Buenas Prácticas para API REST con Laravel

Contenido del curso

Buenas prácticas a nivel general

Creación del proyecto

Planificación y mantenimiento

Funciones de seguridad

API Testing

API Breaking Changes

Conclusiones

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0013:48

Automatiza pruebas de API en Laravel

Curso de Estándares y Buenas Prácticas para API REST con Laravel

Clase 21 de 29

Clase 21 / 29

Recursos

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.

Kenneth Angulo L

Hace 2 años

Sobre el testing, si puedo aportar varias cosas compañeros, y ya que estamos dentro del curso buenas prácticas:

Organizar el código de las pruebas en tres etapas, esto lo hará mucho más fácil de leer y entender:

//Arrange 🛠

Inicializa y prepara el sistema que vas a probar, prepara el escenario, prepara las dependencias.

//Act ⚙️

Es donde se ejecuta el método o la acción que va a producir el resultado que vamos a verificar.

//Assert ✅

Esta es la fase de verificación, donde se va a confirmar que el resultado obtenido o generado en la fase anterior sea el resultado esperado.

Ah ¡ y Una cosa muy obvia pero que pasamos por alto, usar nombres muy descriptivos para las pruebas.

Con esto en mente el código de la clase lo organizamos así:

public function test_category_index_page_is_displayed(): void
{
	//Arrange 🛠
	Sanctum::actingAs(User::factory()->create());
	$categories = Category::factory(2)->create();

	//Act ⚙️
	$response = $this->getJson('/api/v1/categories');

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

Kenneth Angulo L

Hace 2 años

Otro ejemplo :

Buenas prácticas a nivel general

Buenas prácticas para diseñar una API REST

¿Qué son los HTTP Status Codes?

Qué hace cada método HTTP

Creación del proyecto

Migrações e relações de dados em Laravel

Factories y seeders para poblar tu API en Laravel

Consultas API con Laravel: Rutas y Controladores

Consultas con relaciones en Laravel API

Planificación y mantenimiento

Planificación de rutas REST en Laravel

Recursos y colecciones en Laravel API

Recursos anidados en Laravel API

Cómo reducir 932 consultas con Telescope

CRUD de Recetas con Laravel y Symfony en Visual Studio Code

Validación de Datos en Aplicaciones Web con Laravel

Funciones de seguridad

Autenticación vs. autorización

Proteger rutas de API con Sanctum

Ruta de login y tokens con Sanctum

Corrección de bugs de seguridad en aplicaciones web

Políticas de acceso en Laravel con Artisan

Upload e validação de imagens em Laravel

Qué es autenticación en la web

API Testing

Automatiza pruebas de API en Laravel

Testing de Módulos Administrativos en Visual Studio Code

Testing de recetas con PHP Artisan

Pruebas de Creación de Datos en Aplicaciones Web

Test de actualización de recetas en Laravel

API Breaking Changes

Versionado de API en Laravel con v1 y v2

Desarrollo de API con TDD: Implementación de Versión 2

Conclusiones

Desarrollo de API RESTful con Laravel: Buenas Prácticas y Seguridad

Buenas prácticas finales para tu API en Laravel

Automatiza pruebas de API en Laravel