Ir al contenido principal

Unit tests y feature tests en Laravel

 ¿Qué son en Laravel los unit tests y los feature tests?

Ambos son tipos de pruebas automatizadas en Laravel, pero se enfocan en diferentes niveles de tu aplicación. Piensa en ellas como dos formas de evaluar la calidad de tu código: los unit tests examinan los componentes más pequeños, mientras que los feature tests comprueban el comportamiento de la aplicación en su conjunto.


Unit Tests (Pruebas Unitarias)

Un unit test prueba una "unidad" de código de forma aislada. Una unidad es la parte más pequeña que puedes probar de forma lógica, como una única función, un método de una clase o un modelo. El objetivo es verificar que cada pieza individual de tu código funcione correctamente por sí misma, sin depender de otras partes.

  • ¿Qué prueban? Lógica de negocio, cálculos, métodos de modelos o clases de ayuda.

  • ¿Qué NO prueban? Interacción con la base de datos, solicitudes HTTP, vistas, o cualquier cosa que dependa del sistema en su conjunto.

  • Velocidad: Son muy rápidos, ya que no necesitan recursos externos.

  • Ejemplo: Probar que un método en tu clase Calculator devuelva el resultado correcto de una suma, sin importar si está conectado a una interfaz de usuario o a una base de datos.

  • Ejemplo de Unit Test
    <?php

    namespace Tests\Unit;

    use PHPUnit\Framework\TestCase;

    class CalculatorTest extends TestCase
    {
    /** @test */
    public function it_can_add_two_numbers()
    {
    $calculator = new \App\Services\Calculator();
    $result = $calculator->add(5, 3);

    $this->assertEquals(8, $result);
    }
    }

Feature Tests (Pruebas de Funcionalidad)

Un feature test (también llamado prueba de integración) comprueba una "funcionalidad" completa de tu aplicación, como el flujo de un usuario al interactuar con ella. Estas pruebas simulan una petición HTTP real a tu aplicación y verifican el resultado. Su objetivo es asegurar que todos los componentes (rutas, controladores, bases de datos, vistas) trabajen juntos correctamente. .

  • ¿Qué prueban? Flujos de usuario completos, como un registro, un inicio de sesión, el envío de un formulario, o la visualización de una página.

  • ¿Qué NO prueban? La lógica interna de un solo método o función.

  • Velocidad: Son más lentos que las pruebas unitarias porque necesitan cargar la aplicación, interactuar con la base de datos (generalmente una de prueba) y procesar las peticiones.

  • Ejemplo: Simular que un usuario visita la página de un formulario, lo envía con datos válidos y es redirigido a la página de éxito.

  • Ejemplo de Feature Test
    <?php

    namespace Tests\Feature;

    use Illuminate\Foundation\Testing\RefreshDatabase;
    use Illuminate\Foundation\Testing\WithFaker;
    use Tests\TestCase;

    class PostTest extends TestCase
    {
    use RefreshDatabase;

    /** @test */
    public function a_user_can_create_a_post()
    {
    $response = $this->post('/posts', [
    'title' => 'Mi primer post',
    'body' => 'Contenido del post de prueba.',
    ]);

    $response->assertStatus(200);
    $this->assertDatabaseHas('posts', [
    'title' => 'Mi primer post',
    ]);
    }
    }

En Resumen

CaracterísticaUnit TestsFeature Tests
EnfoqueAisladoIntegrado
AlcanceMétodos/FuncionesFlujos completos
VelocidadRápidoLento
PropósitoAsegurar la lógica internaAsegurar el comportamiento de la aplicación

Ambos tipos de pruebas son esenciales para una base de código robusta. Las pruebas unitarias te dan confianza en que tus componentes individuales funcionan, mientras que las pruebas de funcionalidad te aseguran que la aplicación, como un todo, se comporta como se espera.

Comentarios

Entradas populares de este blog

Crear proyecto de frontend con Vite, React, Tailwind, Typescript y JSX

 ¿Cómo se crea un proyecto exclusivo de frontend con Vite, React, Tailwind, Typescript y JSX? ¡Absolutamente! Entiendo que quieres la guía completa para pasar de cero a tener un proyecto de frontend moderno, vacío y listo para ser llenado con tu código. A continuación, te proporciono un archivo de guía detallada que incluye todos los comandos necesarios para inicializar el proyecto, configurar Tailwind CSS, y los pasos clave para empezar a "poblarlo". Voy a generar un documento Markdown con la guía paso a paso, incluyendo los comandos de terminal y las modificaciones esenciales a los archivos de configuración. Guía: Creación de un Proyecto Frontend Puro (Vite, React, TypeScript, Tailwind) Este documento detalla el proceso para inicializar un proyecto de frontend vacío y optimizado, utilizando Vite como empaquetador, React como librería, TypeScript para tipado y Tailwind CSS para estilizado. 1. Inicialización del Proyecto con Vite Vite es la herramienta más rápida para emp...

Tokens V2

Tokens: Programme to discover tokens, where there are not. Now available at  https://puszcza.gnu.org.ua/projects/tokens/ This is Version 2, for  version 1, go here . Synopsis: use TokensV2; sub printFile; my @FORMAT = ( ['<Message Date=".*?" Time=".*?" DateTime=".*?" SessionID=".*?"><From>(?:<User FriendlyName=".*?"/>)+</From><To>(?:<User FriendlyName=".*?"/>)+</To><Text(?: Style=".*?")?>.*?</Text></Message>',   sub {     my $fh = $_[1];     my ($d, $t, $f, $s, $T) = $_[0] =~ m|<Message Date="(.*?)" Time="(.*?)" DateTime=".*?" SessionID=".*?">(<From>(?:<User FriendlyName=".*?"/>)+</From>)<To>(?:<User FriendlyName=".*?"/>)+</To><Text(?: Style="(.*?)")?>(.*?)</Text></Message>|;     my $F = join '<br />', ...

Perl Net::LDAP::SimpleServer

Adaptaciones sobre el módulo LDAP Server para Windows (Strawberry Perl) Lista de adaptaciones (continúa más abajo): - Relajación de condiciones de bind:     - Cuenta principal (principal account)     - Validación de contraseñas Ubicación del archivo: %Strawberry_Perl%\site\lib\net\ldap\SimpleServer\ProtocolHandler.pm CPAN: http://search.cpan.org/~russoz/Net-LDAP-SimpleServer-0.0.17/lib/Net/LDAP/SimpleServer.pm Código: package Net::LDAP::SimpleServer::ProtocolHandler; use strict; use warnings; # ABSTRACT: LDAP protocol handler used with Net::LDAP::SimpleServer our $VERSION = '0.0.17';    # VERSION use Net::LDAP::Server; use base 'Net::LDAP::Server'; use fields qw(store root_dn root_pw allow_anon); use Carp; use Net::LDAP::LDIF; use Net::LDAP::Util qw{canonical_dn}; use Net::LDAP::FilterMatch; use Net::LDAP::Constant (     qw/LDAP_SUCCESS LDAP_AUTH_UNKNOWN LDAP_INVALID_CREDENTIALS/,   ...