
Springboot Verification
- 1.4k installs
- 238k repo stars
- Updated August 5, 2026
- affaan-m/ecc
This is a copy of springboot-verification by affaan-m - installs and ranking accrue to the original listing.
springboot-verification is a Claude Code skill that runs a repeatable build-test-security verification loop for Spring Boot services before pull requests or deployments.
About
springboot-verification is an ECC-origin agent skill that chains Maven/Gradle build, static analysis, unit and integration tests with coverage thresholds, security scans, and diff review into one repeatable gate for Spring Boot microservices. Developers reach for it before opening a PR, after large refactors or dependency bumps, and immediately prior to staging or production deploys when a single missed regression or CVE would be costly. The skill encodes when to activate the full pipeline versus a lighter check and documents coverage thresholds and scan expectations so agents do not skip steps. It targets Java/Spring teams who want agent-driven CI parity on a laptop without wiring a custom script each sprint.
- Full verification loop: build → static analysis → tests with coverage → security scans → diff review
- Supports both Maven and Gradle Spring Boot projects
- Enforces 80%+ test coverage thresholds with JaCoCo reports
- Runs before PRs, after refactoring, and pre-deployment
- Includes unit test patterns using Mockito for service logic
Springboot Verification by the numbers
- 1,399 all-time installs (skills.sh)
- +84 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/affaan-m/ecc --skill springboot-verificationAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1.4k |
|---|---|
| repo stars | ★ 238k |
| Last updated | August 5, 2026 |
| Repository | affaan-m/ecc ↗ |
How do you verify Spring Boot services before PRs?
Run a repeatable verification loop that combines build, static analysis, tests with coverage, security scans, and diff review for Spring Boot services.
Who is it for?
Java developers shipping Spring Boot APIs who want one agent-triggered verification gate before every PR or deploy.
Skip if: Teams on non-JVM stacks or projects that already enforce an identical multi-stage CI pipeline with no local gaps to close.
When should I use this skill?
A Spring Boot service changed and the developer is about to open a PR, merge to main, or deploy to staging/production.
What you get
Passing build artifacts, static-analysis report, test coverage summary, security scan results, and reviewed diff checklist.
- coverage report
- security scan output
- build log
Files
Bucle de Verificación Spring Boot
Ejecutar antes de PRs, después de cambios importantes y antes del despliegue.
Cuándo Activar
- Antes de abrir un pull request para un servicio Spring Boot
- Después de refactorizaciones importantes o actualizaciones de dependencias
- Verificación previa al despliegue para staging o producción
- Ejecutar el pipeline completo de build → lint → test → escaneo de seguridad
- Validar que la cobertura de pruebas cumpla los umbrales
Fase 1: Build
mvn -T 4 clean verify -DskipTests
# o
./gradlew clean assemble -x testSi el build falla, detener y corregir.
Fase 2: Análisis Estático
Maven (plugins comunes):
mvn -T 4 spotbugs:check pmd:check checkstyle:checkGradle (si está configurado):
./gradlew checkstyleMain pmdMain spotbugsMainFase 3: Pruebas + Cobertura
mvn -T 4 test
mvn jacoco:report # verificar cobertura 80%+
# o
./gradlew test jacocoTestReportReporte:
- Total de pruebas, pasadas/fallidas
- % de cobertura (líneas/ramas)
Pruebas Unitarias
Probar la lógica del servicio en aislamiento con dependencias mockeadas:
@ExtendWith(MockitoExtension.class)
class UserServiceTest {
@Mock private UserRepository userRepository;
@InjectMocks private UserService userService;
@Test
void createUser_validInput_returnsUser() {
var dto = new CreateUserDto("Alice", "alice@example.com");
var expected = new User(1L, "Alice", "alice@example.com");
when(userRepository.save(any(User.class))).thenReturn(expected);
var result = userService.create(dto);
assertThat(result.name()).isEqualTo("Alice");
verify(userRepository).save(any(User.class));
}
@Test
void createUser_duplicateEmail_throwsException() {
var dto = new CreateUserDto("Alice", "existing@example.com");
when(userRepository.existsByEmail(dto.email())).thenReturn(true);
assertThatThrownBy(() -> userService.create(dto))
.isInstanceOf(DuplicateEmailException.class);
}
}Pruebas de Integración con Testcontainers
Probar contra una base de datos real en lugar de H2:
@SpringBootTest
@Testcontainers
class UserRepositoryIntegrationTest {
@Container
static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:16-alpine")
.withDatabaseName("testdb");
@DynamicPropertySource
static void configureProperties(DynamicPropertyRegistry registry) {
registry.add("spring.datasource.url", postgres::getJdbcUrl);
registry.add("spring.datasource.username", postgres::getUsername);
registry.add("spring.datasource.password", postgres::getPassword);
}
@Autowired private UserRepository userRepository;
@Test
void findByEmail_existingUser_returnsUser() {
userRepository.save(new User("Alice", "alice@example.com"));
var found = userRepository.findByEmail("alice@example.com");
assertThat(found).isPresent();
assertThat(found.get().getName()).isEqualTo("Alice");
}
}Pruebas de API con MockMvc
Probar la capa controller con el contexto completo de Spring:
@WebMvcTest(UserController.class)
class UserControllerTest {
@Autowired private MockMvc mockMvc;
@MockBean private UserService userService;
@Test
void createUser_validInput_returns201() throws Exception {
var user = new UserDto(1L, "Alice", "alice@example.com");
when(userService.create(any())).thenReturn(user);
mockMvc.perform(post("/api/users")
.contentType(MediaType.APPLICATION_JSON)
.content("""
{"name": "Alice", "email": "alice@example.com"}
"""))
.andExpect(status().isCreated())
.andExpect(jsonPath("$.name").value("Alice"));
}
@Test
void createUser_invalidEmail_returns400() throws Exception {
mockMvc.perform(post("/api/users")
.contentType(MediaType.APPLICATION_JSON)
.content("""
{"name": "Alice", "email": "not-an-email"}
"""))
.andExpect(status().isBadRequest());
}
}Fase 4: Escaneo de Seguridad
# CVEs de dependencias
mvn org.owasp:dependency-check-maven:check
# o
./gradlew dependencyCheckAnalyze
# Secretos en código fuente
grep -rn "password\s*=\s*\"" src/ --include="*.java" --include="*.yml" --include="*.properties"
grep -rn "sk-\|api_key\|secret" src/ --include="*.java" --include="*.yml"
# Secretos (historial de git)
git secrets --scan # si está configuradoHallazgos Comunes de Seguridad
# Verificar System.out.println (usar logger en su lugar)
grep -rn "System\.out\.print" src/main/ --include="*.java"
# Verificar mensajes de excepción en bruto en respuestas
grep -rn "e\.getMessage()" src/main/ --include="*.java"
# Verificar CORS comodín
grep -rn "allowedOrigins.*\*" src/main/ --include="*.java"Fase 5: Lint/Formato (compuerta opcional)
mvn spotless:apply # si se usa el plugin Spotless
./gradlew spotlessApplyFase 6: Revisión de Diff
git diff --stat
git diffLista de verificación:
- Sin logs de depuración residuales (
System.out,log.debugsin guardias) - Errores y códigos HTTP con significado
- Transacciones y validación presentes donde se necesitan
- Cambios de configuración documentados
Plantilla de Salida
REPORTE DE VERIFICACIÓN
=======================
Build: [PASS/FAIL]
Estático: [PASS/FAIL] (spotbugs/pmd/checkstyle)
Pruebas: [PASS/FAIL] (X/Y pasadas, Z% cobertura)
Seguridad: [PASS/FAIL] (hallazgos CVE: N)
Diff: [X archivos modificados]
General: [LISTO / NO LISTO]
Problemas a Corregir:
1. ...
2. ...Modo Continuo
- Volver a ejecutar las fases ante cambios significativos o cada 30–60 minutos en sesiones largas
- Mantener un bucle corto:
mvn -T 4 test+ spotbugs para retroalimentación rápida
Recuerda: La retroalimentación rápida supera las sorpresas tardías. Mantener la compuerta estricta — tratar las advertencias como defectos en sistemas de producción.
Related skills
How it compares
Pick this over generic test runners when you need Spring Boot-specific coverage thresholds, security scans, and diff review in one agent workflow.
FAQ
When should springboot-verification run?
springboot-verification should run before opening a pull request, after major refactors or dependency updates, and immediately before staging or production deployments for Spring Boot services.
What does springboot-verification check?
springboot-verification checks build success, static analysis, unit and integration tests with coverage thresholds, security scans, and a diff review so Spring Boot changes meet release quality bars.