Muchas aplicaciones se organizan en capas. Cada capa cumple una responsabilidad: recibir solicitudes, aplicar reglas de negocio, acceder a datos, comunicarse con otros servicios o preparar respuestas.
Las pruebas de integración entre capas verifican que esas partes colaboren correctamente. No se enfocan en una función aislada ni necesariamente en el sistema completo, sino en el recorrido de una operación a través de varias capas.
En este tema veremos cómo probar la integración entre controladores, servicios, repositorios y otras capas habituales de una aplicación.
Una arquitectura por capas organiza el código separando responsabilidades. Aunque los nombres cambian según la tecnología, una estructura común incluye:
Esta separación ayuda a mantener el código organizado, pero también crea puntos de integración que deben probarse.
Integrar capas significa comprobar que una solicitud o acción pueda pasar correctamente de una capa a otra, respetando datos, contratos y responsabilidades.
Por ejemplo, al crear un cliente:
La integración entre controlador y servicio verifica que la capa de entrada invoque correctamente la lógica de negocio.
Aspectos que conviene probar:
Este tipo de prueba ayuda a detectar errores de mapeo, validación y manejo de respuestas.
La integración entre servicio y repositorio verifica que la lógica de negocio use correctamente la capa de datos.
Puede comprobar:
Esta integración es muy importante porque muchas reglas de negocio dependen del estado persistido.
La integración entre repositorio y base de datos verifica que las consultas reales funcionen contra el esquema real de prueba.
Debe revisar:
Este nivel detecta problemas que no aparecen si el repositorio se simula completamente.
A veces conviene probar varias capas juntas. Por ejemplo, controlador, servicio, repositorio y base de datos. Esto permite verificar un flujo interno más completo sin llegar necesariamente a una prueba end-to-end con interfaz gráfica.
Este tipo de prueba puede responder preguntas como:
El alcance debe definirse con claridad para que la prueba no se vuelva demasiado amplia.
Las validaciones pueden ocurrir en varias capas. Algunas validaciones son de formato de entrada, otras son reglas de negocio y otras son restricciones de datos.
| Tipo de validación | Capa habitual | Ejemplo |
|---|---|---|
| Formato | Controlador o capa de entrada. | Correo con formato inválido. |
| Regla de negocio | Servicio. | No permitir compra sin stock. |
| Restricción de datos | Base de datos. | Documento único para clientes. |
Una prueba de integración puede verificar que las validaciones se ejecuten en el lugar esperado y que sus errores se propaguen correctamente.
Al pasar de una capa a otra, los datos suelen transformarse. Por ejemplo, una solicitud HTTP puede convertirse en un objeto de entrada, luego en una entidad de dominio y finalmente en registros de base de datos.
Errores frecuentes:
Las pruebas entre capas son muy útiles para detectar estos errores de transformación.
Cuando una capa falla, las demás deben manejar esa situación de forma controlada. Por ejemplo, si el servicio detecta una regla inválida, el controlador debe devolver una respuesta adecuada. Si la base de datos rechaza una operación, el servicio debe evitar dejar un estado inconsistente.
Conviene probar errores como:
La prueba debe verificar tanto el error devuelto como el estado final del sistema.
No siempre es necesario integrar todas las capas reales. A veces conviene simular una capa para concentrarse en la colaboración que interesa.
Ejemplos:
La decisión depende del objetivo de la prueba. Simular una capa es válido si esa capa no forma parte del riesgo que queremos verificar.
Integrar todas las capas internas puede ser útil para flujos críticos. Por ejemplo, cuando queremos verificar que una solicitud completa llega hasta la base de datos y vuelve con una respuesta correcta.
Conviene hacerlo cuando:
Este tipo de prueba no debería reemplazar a pruebas más específicas, pero puede dar mucha confianza sobre colaboraciones internas importantes.
Supongamos una prueba para crear un cliente usando controlador, servicio, repositorio y base de datos.
| Paso | Qué se verifica |
|---|---|
| Enviar solicitud con datos válidos. | El controlador recibe y transforma la entrada. |
| Ejecutar regla de documento único. | El servicio consulta el repositorio. |
| Guardar cliente. | El repositorio persiste datos en la base. |
| Consultar cliente creado. | El estado final coincide con lo esperado. |
| Devolver respuesta. | El controlador informa creación exitosa. |
Para el mismo caso, una prueba negativa podría preparar un cliente existente y luego intentar crear otro con el mismo documento.
La prueba debería verificar:
Este ejemplo muestra por qué una prueba entre capas debe revisar respuesta y estado final.
Al probar integración entre capas, suelen aparecer errores como:
Antes de considerar completa una prueba entre capas, conviene revisar:
La integración entre capas permite comprobar que la estructura interna de una aplicación funciona como una colaboración coherente. Cada capa debe cumplir su responsabilidad y comunicarse correctamente con las demás.
Estas pruebas son especialmente útiles para detectar errores de mapeo, validación, persistencia y propagación de errores antes de llegar a pruebas más amplias.
En el próximo tema veremos la integración entre servicios internos, un escenario común en sistemas modulares y distribuidos.