Cómo crear pruebas de integración escalables con GitHub Copilot (basadas en una arquitectura real)

Introducción

Este artículo une dos conceptos previos: la arquitectura de 6 componentes para tests escalables y la técnica de Prompt Chaining con GitHub Copilot. Aplicaremos prompts secuenciales sobre una arquitectura real para acelerar la creación de pruebas de integración.

El problema: escribir pruebas de integración consume tiempo en tareas repetitivas (mocks, builders, flujos). Usando Prompt Chaining sobre una arquitectura clara, convertimos días de trabajo en horas. Sin esta combinación, Copilot genera código frágil que no escala.

Qué entendemos por pruebas de integración escalables

Una suite escalable no solo ejecuta rápido, sino que sobrevive a refactors, cambios de equipo y evolución del producto.

Independencia del entorno

Las pruebas se ejecutan aisladas, en memoria, sin dependencias externas no controladas.

Mocks en fronteras, no en todo

Mockea solo las fronteras: repositorios, clientes HTTP externos, colas. El resto (servicios, controladores, validaciones) debe ser real.

Tests que sobreviven refactors

Validan comportamientos y contratos, no implementaciones internas.

El rol real de GitHub Copilot

Copilot NO diseña arquitectura

No decide cómo estructurar tests, dónde poner mocks, ni cómo organizar flujos. Las decisiones arquitectónicas son tu responsabilidad.

Copilot NO entiende tu dominio

No conoce tus reglas de negocio, validaciones específicas, ni casos edge críticos. Genera código genérico que puede no validar lo importante.

Copilot SÍ acelera lo repetitivo

Si escribiste 2-3 tests con un patrón claro, Copilot replica ese patrón para los siguientes 10-15 tests. Define la arquitectura primero, da ejemplos claros, y deja que Copilot replique.

Arquitectura base para Prompt Chaining

El Prompt Chaining funciona porque cada prompt construye sobre el anterior. Para tests de integración, necesitamos una arquitectura donde cada componente tenga una responsabilidad clara. Usamos la arquitectura de 6 componentes:

tests/integration/
├── InfraIT                # Configuración base compartida
├── api/
│   └── [Entity]Api        # Contrato HTTP del sistema
├── builders/
│   └── [Entity]Builder    # Construcción de datos de prueba
├── mocks/
│   └── [Entity]RepositoryMock # Simulación de BD en memoria
├── flows/
│   └── [Entity]Flows      # Orquestación de casos de uso
└── [Entity]IT             # Suite de tests finales

Por qué la arquitectura es crítica para Prompt Chaining

La arquitectura tiene 6 componentes. Para implementarla con Copilot usamos 7 prompts secuenciales, divididos en 2 lotes: 6 prompts crean los 6 componentes y el Prompt 7 es opcional (extiende los flows con casos edge). Sin arquitectura clara, los prompts no tienen contexto sobre qué generar:

• Lote 1 (4 prompts): InfraIT + [Entity]Api + [Entity]Builder + [Entity]RepositoryMock

• Lote 2 (3 prompts): [Entity]Flows + [Entity]IT + (opcional) flows avanzados sobre [Entity]Flows

• Cada prompt construye sobre los anteriores de forma predecible

Sin esta estructura, los prompts generan código aislado que no se integra: tests que prueban mocks, duplicación masiva, 50+ líneas por test.

Aplicando Prompt Chaining a la arquitectura

Como establecimos en el artículo de Prompt Chaining, por la ventana de contexto limitada de Copilot trabajamos en lotes de máximo 4 prompts. Más de 4 y empiezas a perder información. Por eso dividimos los 7 prompts en 2 lotes: Lote 1 (4 prompts de infraestructura base) y Lote 2 (3 prompts de flujos y tests en un nuevo agente).

Preparación: Define el objetivo

Antes de empezar, ten claro qué endpoint vas a probar: entidad de dominio, casos de uso, validaciones. Esto guía toda la secuencia.

Lote 1: Infraestructura base (4 prompts)

Objetivo: Construir la base sobre la que todo se apoya (InfraIT, [Entity]Api, [Entity]Builder, [Entity]RepositoryMock). Ejecuta estos 4 prompts en secuencia dentro del mismo chat. Usa los botones para ver el contenido completo.

Ejecuta los prompts del Lote 1 en este orden:
1) /lote1-prompt1-infraIT.md
2) /lote1-prompt2-apiClient.md
3) /lote1-prompt3-builder.md
4) /lote1-prompt4-mock.md

Validación después del Lote 1

Valida que la infraestructura funciona y luego cierra el chat:

• InfraIT compila y arranca Spring Boot

• [Entity]Api puede hacer llamadas HTTP

• [Entity]Builder genera objetos válidos

• [Entity]RepositoryMock simula el repositorio en memoria

Si algo falla, corrige aquí (todavía estás en “infraestructura”). Solo cuando todo funciona, sigue al Lote 2.

Importante: Después del Lote 1, cierra el chat de Copilot y abre un nuevo agente. Esto evita que la ventana de contexto se sature y pierda información de los componentes ya creados.

Lote 2: Flujos y tests (3 prompts en nuevo agente)

Objetivo: Usar toda la infraestructura del Lote 1 para crear flujos reutilizables, tests ultra-cortos y flujos avanzados para casos edge. Este lote combina todos los componentes creados en el Lote 1 para generar código de alto nivel que simplifica la escritura de tests.

Casos edge: límites (máx/mín), duplicados, estados inválidos, paginación/filtros vacíos, reglas temporales, flujos multi-paso.

Prompt 7 (opcional): úsalo solo si tu dominio tiene edge cases/reglas que valga encapsular en flows; si es CRUD simple, omítelo.

Abre un nuevo chat de Copilot y ejecuta estos 3 prompts en secuencia; referenciarán los archivos ya creados en el Lote 1:

Los tests finales tienen 3-5 líneas porque reutilizan toda la infraestructura del Lote 1 y los flujos del Lote 2.

Nota: El Prompt 7 solo extiende los flows con casos edge; si no los necesitas, omítelo.

Tests funcionando correctamente

Beneficios reales

Reducción de tiempo

Tiempo de desarrollo: de 2-3 días a 6-8 horas. Builders y flujos se generan rápido, tests finales son ultra-cortos.

Menos fricción para nuevos escenarios

Agregar un nuevo test: de 30 minutos a 5 minutos. Copilot sugiere automáticamente el patrón existente.

Confianza al refactorizar

Tests que pasan = comportamiento público intacto. Acelera mejora continua sin miedo a romper funcionalidad.

Mejor mantenimiento

Nuevos desarrolladores replican el patrón sin ayuda. La consistencia facilita onboarding.

Checklist antes de aceptar código generado

• ¿Valida un flujo real? (no solo mocks)

• ¿Es realmente integración? (múltiples capas trabajando juntas)

• ¿Sobrevive a cambios internos? (valida comportamiento, no implementación)

• ¿Es legible? (nombres descriptivos, aserciones claras)

• ¿Usa la arquitectura correctamente? (Builders, Flows, API)

• ¿Ejecuta rápido? (menos de 200ms con mocks en memoria)

Conclusión

La combinación de Prompt Chaining en 2 lotes + arquitectura de 6 componentes convierte 2-3 días de trabajo en 6-8 horas. Lote 1 construye la infraestructura base (4 prompts), Lote 2 crea flujos, tests y flujos avanzados (3 prompts en nuevo agente). Cada lote respeta la limitación de ventana de contexto de Copilot.

Regla fundamental: Arquitectura primero, Prompt Chaining por lotes después. Sin arquitectura, los prompts generan código aislado. Sin dividir en lotes, Copilot pierde contexto. Juntos, escalan.