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 rutalogin
,
entonces debería devolver la vistaauth.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 URLlogin
,
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');
}
post()
pasandole la ruta para el inicio de sesión y como segundo parámetro, el método post()
acepta un arreglo que será los datos que le enviamos a la solicitud. En este caso, como quiero probar que se muestren los errores de validación, no envío ningún dato.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 UserFactory
caja 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 name
y 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/
Muy buen articulo, me puedes recomendar algún libro o documentación sobre el tema? gracias!!
Muy buen articulo y con ganas de ver la continuación con los test unitarios.
Muy buen contenido, a por el segundo!
pueden recomendar alguna otra fuente donde continuar, en google hay bastante, pero a veces se saltan mucha teoría o no son didácticos.
Gracias!
Muchas gracias por tu comentario Javier, ya esta publicada la segunda parte: https://www.laraveltip.com/haciendo-pruebas-automatizadas-en-laravel-unit-test/ ;). Saludos.
Saludos Matias, excelente página y muy buen artículo, de verdad que encontrar esta web ha sido de bastante ayuda. Solo una pequeña sugerencia y espero que me la permitas, encontre primero la parte 2 de esta guia, y aunque no fue dificil, pues si tarde algo en encontrar esta primera parte, se que es una tonteria pero sugiero linkear esta parte en la otra, te ayuda con SEO y facilita al lector encontrar el principio de tan buena documentación. Gracias nuevamente por tu trabajo, seguire navegando y disfrutando del contenido, saludos.
Muchas gracias Johan por tu comentario y recomendación. Ya lo voy a estar aplicando.
Gracias por tan maravilloso articulo 🙂
Estas son pruebas unitarias automatizadas o funcionales?
Hola Sensey, son funcionales. La parte II son las unitarias.
Gracias Matia, estoy usando laravel 7 y tengo problemas con las aserciones de bases de datos. Cuando hago el post(route(‘register’) …no me genera la nueva ruta HOME. El assertRedirect se termina cayendo.
Verifica que la ruta
Route::get('/')
tenga->name('home')
. O cambia el assert aassertRedirect(url('/'))
o solo con la barra/
.ojo que en laravel 8 por lo menos, la funcion register_creates_and_authenticates_a_user sin faker, falla xq la password debe tener 8 caracteres minimo! saludos! gran articulo! 😀
y –> $user = factory(User::class)->create();
cambia por –> $user = User::factory()->create();
Muchas gracias por la corrección.
Si me quedo viejo el código por el nuevo laravel 😄
Gracias por el comentario!
Buenos días, se que existen pruebas unitarias, de integración y funcionales, dentro de laravel las pruebas funcionales son las mismas que de integración? veo que laravel por defecto solo trae dos carpetas para pruebas unit e feature
Como estas Oscar?
No, las pruebas funcionales no son las mismas que las de integración.
Las funcionales abarcan las de integración y las unitarias pero su contra es que tardan bastante tiempo si cubrís todos los casos con tests funcionales. Conviene crear una carpeta para las de integración y poner ahí los casos de pruebas de integración.
Muchas gracias por tu tiempo Matías. Es que tengo un gran vació nosotros solemos hacer los test tipo:
factory(…)->create()
$this->post(…)
$this->assertOk()
$this->assertDatabaseHas(….)
Pero en una consultoria, nos decían que esas eran pruebas de integración y que no debíamos hacerlas conectando a una base de pruebas sino a mockups, lo cual entiendo para integraciones externas como DHL en las cuales si usamos mockery para los tests pero no vemos sentido en usar mocks para la base de datos ya que ampliaría el margen de error, ya que el mock retornara que la operación fue exitoso sin importar que el código final no funcione.
Por eso tengo la duda, las pruebas de integración son solo para probar componentes externos como integraciones con otros sistemas en las cuales se usan mocks para simular la respuesta? y las que hacemos actualmente si serían las funcionales? o como una funcional incluye una de integración?
De nada Oscar.
Es correcto lo que les dijeron en la consultoría. Las pruebas de integración no tienen que ver con la BD sino con la integración entre componentes de software (pueden ser librerías externas, como con otros módulos de tu aplicación).
Las pruebas de integración tienen más que ver con como escribís tu código.
Por darte un ejemplo bien básico: imagina que tenes que desarrollar una funcionalidad de «Registrar usuario y suscribirlo al newsletter en el mismo momento si el usuario lo desea».
Por un lado vas a desarrollar el «componente de software» para la registración de usuario y por otro lado desarrollas el «componente de software» para la suscripción al newsletter. Vas a tener 2 componentes que se «comunican» entre ellos (ya que la suscripción no se puede producir si el usuario no se registra).
Entonces, vas a tener pruebas unitarias para cada componente que validan sus casos particulares. Después vas a tener pruebas de integración que validan como funciona un componente junto con el otro (sin ir a BD, porque te interesa nada más como se comporta la interacción entre los 2 componentes). Y después vas a tener 1 o 2 pruebas más que sería las funcionales, que son las pruebas más parecidas a las que hace el usuario cuando usa la funcionalidad (por eso los test funcionales si son las únicas que van a BD).
Si escribís toda esta misma funcionalidad en un único método de un controlador, entonces no tendrías test de integración para hacer. Como dije, tiene mucho que ver como escribís tu código.
Te ayude? Cualquier duda, volve a preguntar 👍
Saludos.
Matias Echazarreta Buenos días Matias.
Muchisimas gracias por tu tiempo y ayuda, son muy valiosos y me has despejado varias dudas. Me podrías enviar tus datos de contacto, me interesaría saber si dictas capacitaciones 🙂 mi correo es oscar.sanchez@savne.net
Excelente, si bien la version de laravel es distinta a la actual, el contenido Vale Oro, muchas gracias.