4. Diferencia entre pruebas unitarias, de integración y end-to-end

4.1 Introducción

Las pruebas unitarias son solo un nivel dentro de una estrategia de testing. Para entender bien su utilidad, también debemos distinguirlas de las pruebas de integración y de las pruebas end-to-end.

Estos tres niveles no compiten entre sí. Cada uno responde preguntas diferentes, detecta tipos de problemas distintos y tiene costos diferentes de ejecución y mantenimiento.

En este tema nos concentraremos en comparar los niveles para saber qué conviene probar como unidad, qué conviene probar como integración y qué conviene dejar para una prueba de flujo completo.

4.2 La pregunta que responde cada nivel

Una forma simple de diferenciarlos es observar la pregunta principal que intenta responder cada prueba:

La diferencia central está en el alcance. Cuanto más alto es el nivel, más partes del sistema participan en la prueba.

4.3 Pruebas unitarias

Una prueba unitaria verifica una unidad pequeña de código: una función, método, clase o módulo con una responsabilidad clara. Su objetivo es comprobar lógica específica con datos controlados.

Ejemplo: verificar que una función calcule correctamente el descuento de una compra.

def calcular_descuento(monto):
    if monto > 10000:
        return monto * 0.15
    return 0


def test_compra_mayor_a_10000_recibe_descuento():
    assert calcular_descuento(12000) == 1800

Esta prueba no usa base de datos, navegador, servidor web ni interfaz de usuario. Solo verifica una regla de cálculo.

4.4 Pruebas de integración

Una prueba de integración verifica que dos o más partes del sistema trabajen correctamente juntas. Su foco no está en una unidad aislada, sino en la colaboración entre componentes.

Ejemplos de integración:

• Un servicio guarda correctamente un usuario en una base de datos.
• Un módulo de pedidos consulta stock y registra una reserva.
• Una API recibe una solicitud y llama correctamente a la capa de negocio.
• Un componente usa correctamente una librería externa.

En estas pruebas pueden aparecer recursos reales o simulados, como base de datos de prueba, servidor local o componentes conectados entre sí.

4.5 Pruebas end-to-end

Una prueba end-to-end, también llamada E2E, verifica un flujo completo desde la perspectiva del usuario o de un cliente externo del sistema.

Por ejemplo, en una tienda en línea, una prueba end-to-end podría hacer lo siguiente:

• Abrir la aplicación en un navegador.
• Iniciar sesión.
• Buscar un producto.
• Agregarlo al carrito.
• Confirmar la compra.
• Verificar que se muestre una confirmación.

Este tipo de prueba da confianza sobre el flujo completo, pero suele ser más lenta, más costosa y más sensible a cambios de entorno o interfaz.

4.6 Comparación general

4.7 Ejemplo con la misma funcionalidad

Supongamos una funcionalidad de registro de usuarios. La regla dice que una persona debe tener al menos 18 años para registrarse.

Podemos probar esa funcionalidad en distintos niveles:

La misma regla puede participar en varios niveles, pero cada nivel mira un aspecto diferente del sistema.

4.8 Código de ejemplo para el nivel unitario

La parte más pequeña de la regla puede probarse así:

def puede_registrarse(edad):
    return edad >= 18


def test_edad_17_no_puede_registrarse():
    assert puede_registrarse(17) == False


def test_edad_18_puede_registrarse():
    assert puede_registrarse(18) == True

Estas pruebas son rápidas y directas. Si fallan, sabemos que el problema está en la regla de edad o en la expectativa de la prueba.

4.9 Ejemplo conceptual de integración

Una prueba de integración podría verificar que un servicio usa correctamente esa regla antes de guardar datos:

def test_servicio_registra_usuario_mayor_de_edad(base_de_datos_de_prueba):
    servicio = ServicioRegistro(base_de_datos_de_prueba)

    servicio.registrar(nombre="Ana", edad=18)

    usuario = base_de_datos_de_prueba.buscar_usuario("Ana")
    assert usuario is not None

Aquí ya no estamos probando solo la función de edad. También participa el servicio de registro y una base de datos de prueba. Si falla, puede haber un problema en la validación, en el servicio, en el mapeo de datos o en la persistencia.

4.10 Ejemplo conceptual end-to-end

Una prueba end-to-end podría simular el flujo completo en la interfaz:

def test_usuario_mayor_de_edad_puede_registrarse_en_la_web(navegador):
    navegador.abrir("/registro")
    navegador.escribir("#nombre", "Ana")
    navegador.escribir("#edad", "18")
    navegador.click("#boton-registrar")

    assert navegador.contiene_texto("Registro completado")

Este ejemplo es conceptual. Lo importante es notar que ahora participan la interfaz, el servidor, la validación, la persistencia y la respuesta visible para el usuario.

4.11 Qué defectos detecta mejor cada nivel

4.12 Velocidad y costo de diagnóstico

Las pruebas unitarias suelen ejecutarse en milisegundos o segundos porque no levantan toda la aplicación. Esto permite correrlas con frecuencia mientras desarrollamos.

Las pruebas de integración suelen tardar más porque conectan varias partes. Pueden requerir preparar una base de datos, iniciar servicios o cargar configuraciones.

Las pruebas end-to-end suelen ser las más lentas porque recorren flujos completos y dependen de más elementos. Además, cuando fallan, el diagnóstico puede requerir revisar varias capas del sistema.

4.13 La pirámide de testing

La pirámide de testing es una idea usada para representar una estrategia equilibrada de pruebas automatizadas. En general, propone tener muchas pruebas unitarias, una cantidad menor de pruebas de integración y menos pruebas end-to-end.

La razón es práctica: las pruebas unitarias son rápidas y baratas de ejecutar; las de integración aportan confianza sobre colaboraciones importantes; las end-to-end verifican flujos críticos pero son más costosas.

No debe interpretarse como una regla matemática exacta. Es una guía para evitar depender únicamente de pruebas grandes y lentas.

4.14 Cuándo conviene una prueba unitaria

Conviene elegir una prueba unitaria cuando queremos verificar:

• Una regla de negocio aislable.
• Un cálculo.
• Una validación.
• Una transformación de datos.
• Una decisión basada en condiciones.
• Un cambio de estado dentro de una clase.
• Un error esperado ante datos inválidos.

Si podemos comprobar el comportamiento sin base de datos, navegador ni red, probablemente estamos ante un buen candidato para prueba unitaria.

4.15 Cuándo conviene una prueba de integración

Conviene una prueba de integración cuando el riesgo principal está en la colaboración entre partes. Por ejemplo:

• Un repositorio debe consultar correctamente una base de datos.
• Un servicio debe usar otro componente con los datos adecuados.
• Una API debe recibir una solicitud y transformarla en una operación interna.
• Una capa debe interpretar correctamente la respuesta de otra.
• Una configuración debe conectar módulos que por separado funcionan bien.

Si las unidades funcionan por separado pero no sabemos si colaboran bien, necesitamos una prueba de integración.

4.16 Cuándo conviene una prueba end-to-end

Conviene una prueba end-to-end cuando queremos comprobar un flujo crítico tal como lo usaría una persona o un sistema externo.

Ejemplos:

• Registro completo de un usuario.
• Compra de un producto.
• Recuperación de contraseña.
• Carga y aprobación de una solicitud.
• Publicación de contenido desde la interfaz.

Estas pruebas son valiosas, pero conviene reservarlas para flujos importantes. Si intentamos verificar cada pequeña regla con pruebas end-to-end, la suite puede volverse lenta y difícil de mantener.

4.17 Un error frecuente: probar todo desde arriba

Cuando un equipo comienza a automatizar, a veces intenta probar casi todo desde la interfaz o desde flujos completos. Esto parece atractivo porque se parece al uso real del sistema, pero suele traer problemas.

Si una regla simple falla, una prueba end-to-end puede tardar más en ejecutarse y dar menos información sobre la causa. Además, puede fallar por elementos ajenos a la regla: selectores de interfaz, datos de prueba, sesión, red, tiempos de espera o configuración.

La regla general es elegir el nivel más bajo que permita verificar el comportamiento con claridad. Si una regla puede probarse unitariamente, no hace falta depender siempre de un flujo completo para cubrirla.

4.18 Otro error frecuente: confiar solo en unitarias

El extremo opuesto también es riesgoso. Tener muchas pruebas unitarias no garantiza que la aplicación funcione correctamente cuando sus partes se conectan.

Dos unidades pueden estar bien probadas de manera aislada y aun así fallar al integrarse. Por ejemplo, una función puede devolver una fecha en un formato y otra esperar un formato diferente. Cada una puede pasar sus pruebas unitarias, pero la colaboración puede fallar.

Por eso necesitamos una combinación equilibrada. Las pruebas unitarias son una base importante, pero no reemplazan las pruebas de integración ni las end-to-end.

4.19 Cómo decidir el nivel adecuado

Antes de escribir una prueba, conviene hacer estas preguntas:

• ¿El comportamiento pertenece a una unidad concreta?
• ¿Necesito comprobar colaboración entre componentes?
• ¿El riesgo está en una regla interna o en un flujo completo?
• ¿Puedo verificarlo sin base de datos, red o navegador?
• ¿Qué tan rápido necesito que se ejecute esta prueba?
• Si falla, ¿la prueba me ayudará a encontrar la causa?

Estas preguntas ayudan a ubicar la prueba en el nivel correcto y evitan suites lentas o con pruebas redundantes.

4.20 Qué debes recordar de este tema

• Las pruebas unitarias verifican unidades pequeñas de código.
• Las pruebas de integración verifican colaboración entre partes.
• Las pruebas end-to-end verifican flujos completos desde una perspectiva de usuario o cliente externo.
• Las unitarias suelen ser más rápidas y más fáciles de diagnosticar.
• Las end-to-end dan confianza sobre flujos reales, pero son más costosas.
• No conviene probar todo desde el nivel más alto.
• Tampoco conviene confiar solo en pruebas unitarias.

4.21 Conclusión

Las pruebas unitarias, de integración y end-to-end cumplen funciones distintas. Una estrategia de testing sólida usa cada nivel para lo que mejor sabe comprobar.

En este curso profundizaremos en pruebas unitarias, pero siempre teniendo presente su lugar dentro de una estrategia más amplia. Saber qué no corresponde a una prueba unitaria es tan importante como saber escribirla bien.

En el próximo tema estudiaremos los beneficios y límites de las pruebas unitarias para tener expectativas realistas sobre su valor.