26. Pruebas positivas, negativas y casos límite en integración

26.1 Introducción

Un buen conjunto de pruebas de integración no debe cubrir solamente el camino exitoso. También debe verificar qué ocurre cuando la operación se rechaza, cuando una dependencia falla o cuando los datos están justo en un límite importante.

Las pruebas positivas, negativas y de casos límite observan la misma integración desde perspectivas distintas. Juntas ayudan a comprobar que los componentes colaboran correctamente en condiciones normales y también ante situaciones problemáticas.

En este tema veremos cómo elegir y diseñar estos tipos de escenarios.

26.2 Qué es una prueba positiva

Una prueba positiva verifica que la integración funcione cuando las condiciones son válidas y esperadas.

Ejemplos:

  • Crear una orden con usuario válido, producto activo y stock suficiente.
  • Registrar un cliente con documento no duplicado.
  • Importar un archivo con formato correcto.
  • Procesar un evento válido.
  • Consultar un servicio interno disponible.

Estas pruebas son importantes porque confirman el comportamiento principal que el sistema debe ofrecer.

26.3 Qué debe verificar una prueba positiva

Una prueba positiva no debería limitarse a que no haya errores. Debe verificar el resultado esperado.

Puede comprobar:

  • Respuesta correcta.
  • Datos persistidos.
  • Estados actualizados.
  • Mensajes publicados.
  • Archivos generados.
  • Llamadas realizadas a dependencias.
En integración, una prueba positiva debe comprobar que la colaboración produce el estado final esperado, no solo que la operación termina sin excepción.

26.4 Qué es una prueba negativa

Una prueba negativa verifica cómo responde la integración cuando la operación no debería completarse o cuando ocurre una condición inválida.

Ejemplos:

  • Crear un cliente con correo duplicado.
  • Confirmar compra sin stock suficiente.
  • Importar archivo con columnas faltantes.
  • Procesar evento con identificador inexistente.
  • Consultar una API externa con credencial inválida.

Estas pruebas ayudan a verificar que el sistema rechace correctamente operaciones inválidas y no deje estados inconsistentes.

26.5 Qué debe verificar una prueba negativa

Una prueba negativa debe revisar dos cosas: la respuesta o error esperado, y la ausencia de efectos incorrectos.

Por ejemplo, si una compra se rechaza por falta de stock, deberíamos verificar:

  • Se informa el rechazo.
  • No se crea una orden confirmada.
  • No se descuenta stock.
  • No se registra pago aprobado.
  • No se publica evento de compra confirmada.

Muchas fallas de integración aparecen justamente cuando una operación fallida deja cambios parciales.

26.6 Qué es un caso límite

Un caso límite, o caso borde, verifica valores cercanos a una frontera importante. Son valiosos porque los errores suelen aparecer en los límites de reglas, rangos y estados.

Ejemplos:

  • Comprar exactamente la cantidad disponible en stock.
  • Comprar una unidad más que el stock disponible.
  • Importe igual al máximo permitido.
  • Fecha exactamente en el vencimiento.
  • Archivo con el tamaño máximo aceptado.
  • Lista con cero, uno o muchos elementos.

En integración, los casos límite permiten verificar que varios componentes interpreten la misma frontera de la misma manera.

26.7 Casos límite en datos compartidos

Cuando varios componentes comparten datos, un límite puede interpretarse de forma distinta. Por ejemplo, un servicio puede considerar que una promoción vence el 31 a las 00:00, mientras otro la considera válida durante todo el día 31.

Conviene probar límites relacionados con:

  • Fechas y horarios.
  • Cantidades.
  • Importes.
  • Longitudes de texto.
  • Estados permitidos.
  • Valores mínimos y máximos.

Estos casos detectan desacuerdos entre componentes antes de que lleguen a flujos más amplios.

26.8 Casos positivos en integración con base de datos

En una integración con base de datos, un caso positivo puede verificar que una operación válida persista correctamente los datos.

Ejemplo: crear un cliente válido.

  • Preparar datos de entrada válidos.
  • Ejecutar creación del cliente.
  • Verificar respuesta exitosa.
  • Consultar la base de datos.
  • Confirmar que el cliente fue guardado con los campos esperados.

26.9 Casos negativos en integración con base de datos

Un caso negativo con base de datos puede verificar restricciones o reglas de persistencia.

Ejemplo: documento duplicado.

  • Preparar un cliente existente.
  • Intentar crear otro cliente con el mismo documento.
  • Verificar error esperado.
  • Confirmar que no se creó un segundo registro.
  • Verificar que el cliente original no fue modificado.

26.10 Casos positivos con servicios externos

En una integración con servicio externo, un caso positivo verifica que la respuesta exitosa sea interpretada correctamente.

Ejemplo: pago aprobado.

  • Preparar orden pendiente.
  • Configurar proveedor simulado o sandbox para aprobar el pago.
  • Ejecutar confirmación.
  • Verificar que la orden quede pagada.
  • Guardar identificador de transacción del proveedor.

26.11 Casos negativos con servicios externos

Un caso negativo verifica respuestas de rechazo o error externo.

Ejemplo: pago rechazado.

  • Configurar proveedor para devolver rechazo.
  • Ejecutar confirmación de compra.
  • Verificar que la orden no quede pagada.
  • Confirmar que no se descuente stock definitivamente.
  • Registrar el motivo del rechazo si corresponde.

Este tipo de caso protege al sistema contra estados internos incorrectos generados por respuestas externas.

26.12 Casos límite con procesos asíncronos

En procesos asíncronos, los límites pueden estar relacionados con tiempo, duplicados, orden o cantidad de mensajes.

Ejemplos:

  • El consumidor recibe el mismo mensaje dos veces.
  • El evento llega después del tiempo esperado.
  • Se procesan varios eventos del mismo recurso.
  • Un evento llega con versión nueva del contrato.
  • Una cola contiene un mensaje inválido entre mensajes válidos.

Estos escenarios ayudan a probar robustez del consumidor y consistencia eventual.

26.13 Seleccionar pocos casos valiosos

No es necesario convertir cada combinación posible en una prueba de integración. Estas pruebas suelen ser más costosas que las unitarias, por lo que conviene seleccionar casos representativos y de alto valor.

Prioriza casos donde:

  • La falla tendría alto impacto.
  • Hay varias dependencias involucradas.
  • Los datos atraviesan transformaciones.
  • Existen errores frecuentes en esa integración.
  • Un estado inconsistente sería difícil de corregir.

Los detalles puramente internos pueden cubrirse mejor con pruebas unitarias.

26.14 Combinar tipos de casos

Una integración importante suele necesitar al menos un caso positivo, uno o más negativos y algún límite relevante.

Por ejemplo, para stock:

Tipo Escenario Qué verifica
Positivo Comprar 2 unidades con stock 10. La compra se confirma y el stock baja a 8.
Negativo Comprar 12 unidades con stock 10. La compra se rechaza y el stock no cambia.
Límite Comprar 10 unidades con stock 10. La compra se acepta y el stock queda en 0.
Límite Comprar 11 unidades con stock 10. La compra se rechaza sin cambios parciales.

26.15 Verificar ausencia de efectos

En pruebas negativas y de límite, es muy importante verificar lo que no debe ocurrir.

Ejemplos:

  • No crear registros duplicados.
  • No publicar eventos de éxito.
  • No descontar stock.
  • No enviar correos.
  • No modificar datos de otro usuario.
  • No dejar archivos temporales incompletos.

Estas verificaciones detectan defectos que una simple revisión de respuesta no mostraría.

26.16 Errores comunes

Al diseñar estos escenarios, suelen aparecer errores como:

  • Probar solo caminos positivos.
  • Confundir prueba negativa con prueba de error técnico.
  • No verificar que no haya efectos secundarios indebidos.
  • Agregar demasiados casos límite de bajo valor.
  • No preparar datos específicos para cada caso.
  • No limpiar estados generados por pruebas negativas.
  • Probar reglas internas simples con integración costosa cuando bastaría una prueba unitaria.

26.17 Lista de verificación

Para revisar la cobertura de una integración, podemos preguntar:

  • ¿Existe al menos un caso positivo del flujo principal?
  • ¿Se cubren errores de negocio relevantes?
  • ¿Se cubren errores técnicos importantes?
  • ¿Hay casos límite donde los componentes pueden interpretar distinto la regla?
  • ¿Se verifica el estado final?
  • ¿Se verifica lo que no debe ocurrir?
  • ¿La cantidad de casos es proporcional al riesgo?

26.18 Qué debes recordar de este tema

  • Las pruebas positivas validan el camino esperado.
  • Las pruebas negativas validan rechazos, errores y ausencia de cambios indebidos.
  • Los casos límite prueban valores cercanos a fronteras importantes.
  • En integración, el estado final suele ser tan importante como la respuesta.
  • No es necesario probar todas las combinaciones en integración; hay que priorizar por riesgo.
  • Verificar lo que no debe ocurrir es clave para detectar cambios parciales incorrectos.

26.19 Conclusión

Las pruebas positivas, negativas y de casos límite se complementan. Juntas permiten comprobar que una integración funciona cuando todo está bien, falla de forma controlada cuando algo no corresponde y maneja correctamente las fronteras importantes.

Una suite de integración equilibrada no necesita cubrir todas las combinaciones, pero sí debe cubrir los escenarios que más riesgo concentran.

En el próximo tema veremos trazabilidad entre requisitos, interfaces y pruebas de integración.