Bucle de Verificación Quarkus
Ejecutar antes de PRs, después de cambios importantes y antes del despliegue.
Cuándo activarlo
- Antes de abrir un pull request para un servicio Quarkus
- Después de una refactorización importante o actualización de dependencias
- Verificación previa al despliegue en staging o producción
- Ejecución del pipeline completo: compilación → lint → pruebas → escaneo de seguridad → compilación nativa
- Validación de que la cobertura de pruebas cumple los umbrales (80%+)
- Prueba de compatibilidad con imágenes nativas
Fase 1: Compilación
# Maven
mvn clean verify -DskipTests
# Gradle
./gradlew clean assemble -x test
Si la compilación falla, deténgase y corrija los errores de compilación.
Fase 2: Análisis estático
Checkstyle, PMD, SpotBugs (Maven)
mvn checkstyle:check pmd:check spotbugs:check
SonarQube (si está configurado)
mvn sonar:sonar \
-Dsonar.projectKey=my-quarkus-project \
-Dsonar.host.url=http://localhost:9000 \
-Dsonar.login=${SONAR_TOKEN}
Problemas comunes a abordar
- Importaciones o variables no utilizadas
- Métodos complejos (alta complejidad ciclomática)
- Posibles desreferencias de puntero nulo
- Problemas de seguridad señalados por SpotBugs
Fase 3: Pruebas + Cobertura
# Ejecutar todas las pruebas
mvn clean test
# Generar informe de cobertura
mvn jacoco:report
# Aplicar umbral de cobertura (80%)
mvn jacoco:check
# O con Gradle
./gradlew test jacocoTestReport jacocoTestCoverageVerification
Categorías de pruebas
Pruebas unitarias
Probar la lógica del servicio con dependencias simuladas:
@ExtendWith(MockitoExtension.class)
class UserServiceTest {
@Mock UserRepository userRepository;
@InjectMocks UserService userService;
@Test
void createUser_validInput_returnsUser() {
var dto = new CreateUserDto("Alice", "[email protected]");
// Panache persist() es void — usar doNothing + verify
doNothing().when(userRepository).persist(any(User.class));
User result = userService.create(dto);
assertThat(result.name).isEqualTo("Alice");
verify(userRepository).persist(any(User.class));
}
}
Pruebas de integración
Probar con base de datos real (Testcontainers):
@QuarkusTest
@QuarkusTestResource(PostgresTestResource.class)
class UserRepositoryIntegrationTest {
@Inject
UserRepository userRepository;
@Test
@Transactional
void findByEmail_existingUser_returnsUser() {
User user = new User();
user.name = "Alice";
user.email = "[email protected]";
userRepository.persist(user);
Optional<User> found = userRepository.findByEmail("[email protected]");
assertThat(found).isPresent();
assertThat(found.get().name).isEqualTo("Alice");
}
}
Pruebas de API
Probar endpoints REST con REST Assured:
@QuarkusTest
class UserResourceTest {
@Test
void createUser_validInput_returns201() {
given()
.contentType(ContentType.JSON)
.body("""
{"name": "Alice", "email": "[email protected]"}
""")
.when().post("/api/users")
.then()
.statusCode(201)
.body("name", equalTo("Alice"));
}
@Test
void createUser_invalidEmail_returns400() {
given()
.contentType(ContentType.JSON)
.body("""
{"name": "Alice", "email": "invalid"}
""")
.when().post("/api/users")
.then()
.statusCode(400);
}
}
Informe de cobertura
Consulte target/site/jacoco/index.html para obtener la cobertura detallada:
- Cobertura de líneas total (objetivo: 80%+)
- Cobertura de ramas (objetivo: 70%+)
- Identificar rutas críticas no cubiertas
Fase 4: Escaneo de seguridad
Vulnerabilidades de dependencias (Maven)
mvn org.owasp:dependency-check-maven:check
Revise target/dependency-check-report.html para ver CVEs.
Auditoría de seguridad de Quarkus
# Comprobar extensiones vulnerables
mvn quarkus:audit
# Listar todas las extensiones
mvn quarkus:list-extensions
OWASP ZAP (Pruebas de seguridad de API)
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-api-scan.py \
-t http://localhost:8080/q/openapi \
-f openapi
Comprobaciones de seguridad comunes
- Todos los secretos en variables de entorno (no en el código)
- Validación de entrada en todos los endpoints
- Autenticación/autorización configurada
- CORS configurado correctamente
- Cabeceras de seguridad configuradas
- Contraseñas hasheadas con BCrypt
- Protección contra inyección SQL (consultas parametrizadas)
- Limitación de velocidad en endpoints públicos
Fase 5: Compilación nativa
Pruebe la compatibilidad con la imagen nativa de GraalVM:
# Compilar ejecutable nativo
mvn package -Dnative
# O con contenedor
mvn package -Dnative -Dquarkus.native.container-build=true
# Probar ejecutable nativo
./target/*-runner
# Ejecutar pruebas de humo básicas
curl http://localhost:8080/q/health/live
curl http://localhost:8080/q/health/ready
Solución de problemas de imágenes nativas
Problemas comunes:
- Reflexión: Añadir configuración de reflexión para clases dinámicas
- Recursos: Incluir recursos con
quarkus.native.resources.includes - JNI: Registrar clases JNI si se usan bibliotecas nativas
Ejemplo de configuración de reflexión:
@RegisterForReflection(targets = {MyDynamicClass.class})
public class ReflectionConfiguration {}
Fase 6: Pruebas de rendimiento
Pruebas de carga con K6
// load-test.js
import http from 'k6/http';
import { check } from 'k6';
export const options = {
stages: [
{ duration: '30s', target: 50 },
{ duration: '1m', target: 100 },
{ duration: '30s', target: 0 },
],
};
export default function () {
const res = http.get('http://localhost:8080/api/markets');
check(res, {
'status is 200': (r) => r.status === 200,
'response time < 200ms': (r) => r.timings.duration < 200,
});
}
Ejecutar:
k6 run load-test.js
Métricas a monitorizar
- Tiempo de respuesta (p50, p95, p99)
- Rendimiento (solicitudes/segundo)
- Tasa de error
- Uso de memoria
- Uso de CPU
Fase 7: Health checks
# Liveness
curl http://localhost:8080/q/health/live
# Readiness
curl http://localhost:8080/q/health/ready
# Todos los health checks
curl http://localhost:8080/q/health
# Métricas (si está habilitado)
curl http://localhost:8080/q/metrics
Respuestas esperadas:
{
"status": "UP",
"checks": [
{
"name": "Database connection",
"status": "UP"
}
]
}
Fase 8: Construcción de imagen de contenedor
# Construir imagen de contenedor
mvn package -Dquarkus.container-image.build=true
# O con registro específico
mvn package \
-Dquarkus.container-image.build=true \
-Dquarkus.container-image.registry=docker.io \
-Dquarkus.container-image.group=myorg \
-Dquarkus.container-image.tag=1.0.0
# Probar contenedor
docker run -p 8080:8080 myorg/my-quarkus-app:1.0.0
Escaneo de seguridad del contenedor
# Trivy
trivy image myorg/my-quarkus-app:1.0.0
# Grype
grype myorg/my-quarkus-app:1.0.0
Fase 9: Validación de configuración
# Comprobar todas las propiedades de configuración
mvn quarkus:info
# Listar todas las fuentes de configuración
curl http://localhost:8080/q/dev/io.quarkus.quarkus-vertx-http/config
Comprobaciones específicas del entorno
- URLs de base de datos configuradas por entorno
- Secretos externalizados (Vault, variables de entorno)
- Niveles de registro apropiados
- Orígenes CORS configurados correctamente
- Limitación de velocidad configurada
- Monitorización/trazado habilitado
Fase 10: Revisión de documentación
- Documentación OpenAPI/Swagger actualizada (
/q/swagger-ui) - README con instrucciones de configuración
- Cambios en la API documentados
- Guía de migración para cambios importantes
- Propiedades de configuración documentadas
Generar especificación OpenAPI:
curl http://localhost:8080/q/openapi -o openapi.json
Lista de verificación
Calidad del código
- La compilación pasa sin advertencias
- Análisis estático limpio (sin problemas altos/medios)
- El código sigue las convenciones del equipo
- Sin código comentado ni TODOs en el PR
Pruebas
- Todas las pruebas pasan
- Cobertura de código ≥ 80%
- Pruebas de integración con base de datos real
- Pruebas de seguridad pasan
- Rendimiento dentro de límites aceptables
Seguridad
- Sin vulnerabilidades de dependencias
- Autenticación/autorización probada
- Validación de entrada completa
- Secretos no en el código fuente
- Cabeceras de seguridad configuradas
Despliegue
- Compilación nativa exitosa
- La imagen del contenedor se construye
- Los health checks responden correctamente
- Configuración válida para el entorno de destino
Imagen nativa
- El ejecutable nativo se compila
- Las pruebas nativas pasan
- Tiempo de inicio < 100ms
- Huella de memoria aceptable
Script de verificación automatizado
#!/bin/bash
set -e
echo "=== Fase 1: Compilación ==="
mvn clean verify -DskipTests
echo "=== Fase 2: Análisis estático ==="
mvn checkstyle:check pmd:check spotbugs:check
echo "=== Fase 3: Pruebas + Cobertura ==="
mvn test jacoco:report jacoco:check
echo "=== Fase 4: Escaneo de seguridad ==="
mvn org.owasp:dependency-check-maven:check
echo "=== Fase 5: Compilación nativa ==="
mvn package -Dnative -Dquarkus.native.container-build=true
echo "=== Todas las fases completadas ==="
echo "Revise los informes:"
echo " - Cobertura: target/site/jacoco/index.html"
echo " - Seguridad: target/dependency-check-report.html"
echo " - Nativo: target/*-runner"
Integración con CI/CD
Ejemplo de GitHub Actions
name: Verificación
on: [push, pull_request]
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- name: Configurar JDK 21
uses: actions/setup-java@v5
with:
java-version: '21'
distribution: 'temurin'
- name: Cachear paquetes Maven
uses: actions/cache@v6
with:
path: ~/.m2
key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
- name: Compilar
run: mvn clean verify -DskipTests
- name: Pruebas con cobertura
run: mvn test jacoco:report jacoco:check
- name: Escaneo de seguridad
run: mvn org.owasp:dependency-check-maven:check
- name: Subir cobertura
uses: codecov/codecov-action@v7
with:
token: ${{ secrets.CODECOV_TOKEN }}
files: target/site/jacoco/jacoco.xml
Mejores prácticas
- Ejecute el bucle de verificación antes de cada PR
- Automatícelo en el pipeline CI/CD
- Corrija los problemas inmediatamente; no acumule deuda técnica
- Mantenga la cobertura por encima del 80%
- Actualice las dependencias regularmente
- Pruebe la compilación nativa periódicamente
- Monitorice las tendencias de rendimiento
- Documente los cambios importantes
- Revise los resultados de los escaneos de seguridad
- Valide la configuración para cada entorno