Spring Boot Verification Loop

Автоматизируйте CI/CD цикл для Spring Boot с помощью Claude Code. Выполняйте сборку, статический анализ, глубокое тестирование и проверки безопасности для высококачественных Java-приложений.

Безопасность и тестирование ★ 172,009 GitHub (172,009 ★)

Spring Boot Verification Loop — это специализированный навык, предназначенный для стандартизации процесса проверки Java-микросервисов. Он направляет AI-агентов через строгий многоэтапный рабочий процесс, включающий оптимизированную сборку, статический анализ кода с помощью SpotBugs и Checkstyle, многоуровневое тестирование (модульное, интеграционное с Testcontainers и MockMvc), а также аудит безопасности OWASP. Этот навык гарантирует, что каждое изменение кода готово к продакшену, безопасно и соответствует требованиям покрытия до того, как попадет в pull request или пайплайн развертывания.

Ключевые возможности

01Проверка зависимостей OWASP и сканирование жестко заданных секретов.

02Автоматизированная оптимизация и проверка сборки Maven и Gradle.

03172 009 звёзд на GitHub

04Стандартизированная отчетность о проверках для готовности PR и релизов.

05Интегрированный статический анализ с помощью SpotBugs, PMD и Checkstyle.

06Поддержка многоуровневого тестирования, включая Testcontainers и API-тесты MockMvc.

Варианты использования

01Аудит безопасности сервисов Spring Boot на наличие уязвимостей и утечек учетных данных.

02Валидация крупных рефакторингов или обновлений фреймворка с помощью всестороннего тестового покрытия.

03Проверка перед pull request для гарантии отсутствия регрессий и высокого качества кода.

name	springboot-verification
description	Verification loop for Spring Boot projects: build, static analysis, tests with coverage, security scans, and diff review before release or PR.
origin	ECC

Spring Boot Doğrulama Döngüsü

PR'lardan önce, büyük değişikliklerden sonra ve deployment öncesi çalıştırın.

Ne Zaman Aktif Edilir

Spring Boot servisi için pull request açmadan önce
Büyük refactoring veya bağımlılık yükseltmelerinden sonra
Staging veya production için deployment öncesi doğrulama
Tam build → lint → test → güvenlik taraması pipeline'ı çalıştırma
Test kapsamının eşikleri karşıladığını doğrulama

Faz 1: Build

mvn -T 4 clean verify -DskipTests
# veya
./gradlew clean assemble -x test

Build başarısız olursa, durdurun ve düzeltin.

Faz 2: Static Analiz

Maven (yaygın plugin'ler):

mvn -T 4 spotbugs:check pmd:check checkstyle:check

Gradle (yapılandırılmışsa):

./gradlew checkstyleMain pmdMain spotbugsMain

Faz 3: Testler + Kapsam

mvn -T 4 test
mvn jacoco:report   # 80%+ kapsam doğrula
# veya
./gradlew test jacocoTestReport

Rapor:

Toplam testler, geçen/başarısız
Kapsam % (satırlar/dallar)

Unit Testler

Mock bağımlılıklarla izole olarak servis mantığını test edin:

@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);
  }
}

Testcontainers ile Entegrasyon Testleri

H2 yerine gerçek bir veritabanına karşı test edin:

@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");
  }
}

MockMvc ile API Testleri

Tam Spring context ile controller katmanını test edin:

@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());
  }
}

Faz 4: Güvenlik Taraması

# Bağımlılık CVE'leri
mvn org.owasp:dependency-check-maven:check
# veya
./gradlew dependencyCheckAnalyze

# Kaynakta gizli bilgiler
grep -rn "password\s*=\s*\"" src/ --include="*.java" --include="*.yml" --include="*.properties"
grep -rn "sk-\|api_key\|secret" src/ --include="*.java" --include="*.yml"

# Gizli bilgiler (git geçmişi)
git secrets --scan  # yapılandırılmışsa

Yaygın Güvenlik Bulguları

# System.out.println kontrolü (yerine logger kullan)
grep -rn "System\.out\.print" src/main/ --include="*.java"

# Yanıtlarda ham exception mesajları kontrolü
grep -rn "e\.getMessage()" src/main/ --include="*.java"

# Wildcard CORS kontrolü
grep -rn "allowedOrigins.*\*" src/main/ --include="*.java"

Faz 5: Lint/Format (opsiyonel kapı)

mvn spotless:apply   # Spotless plugin kullanıyorsanız
./gradlew spotlessApply

Faz 6: Diff İncelemesi

git diff --stat
git diff

Kontrol listesi:

Debug logları kalmamış (System.out, koruma olmadan log.debug)
Anlamlı hatalar ve HTTP durumları
Gerekli yerlerde transaction'lar ve validation mevcut
Config değişiklikleri belgelenmiş

Çıktı Şablonu

DOĞRULAMA RAPORU
===================
Build:     [GEÇTİ/BAŞARISIZ]
Static:    [GEÇTİ/BAŞARISIZ] (spotbugs/pmd/checkstyle)
Testler:   [GEÇTİ/BAŞARISIZ] (X/Y geçti, Z% kapsam)
Güvenlik:  [GEÇTİ/BAŞARISIZ] (CVE bulguları: N)
Diff:      [X dosya değişti]

Genel:     [HAZIR / HAZIR DEĞİL]

Düzeltilecek Sorunlar:
1. ...
2. ...

Sürekli Mod

Önemli değişikliklerde veya uzun oturumlarda her 30-60 dakikada bir fazları yeniden çalıştırın
Kısa döngü tutun: hızlı geri bildirim için mvn -T 4 test + spotbugs

Unutmayın: Hızlı geri bildirim geç sürprizleri yener. Kapıyı sıkı tutun—production sistemlerinde uyarıları kusur olarak değerlendirin.

🔍 Что это

Spring Boot Verification Loop — это автоматизированный цикл проверки качества для Spring Boot проектов. Он объединяет сборку, статический анализ кода, юнит- и интеграционные тесты с оценкой покрытия, сканирование уязвимостей в зависимостях и финальный diff-ревью. Цель — выявить проблемы на ранних стадиях (до PR или релиза) и гарантировать, что код готов к production.

⚙️ Как работает

Цикл состоит из шести фаз, каждая из которых может остановить pipeline при критических ошибках. Фазы можно запускать как последовательно, так и выборочно для быстрой обратной связи.

🔨 Фаза 1: Сборка

Проект собирается с пропуском тестов для экономии времени: mvn -T 4 clean verify -DskipTests или ./gradlew clean assemble -x test. Если сборка падает — дальнейшие шаги не имеют смысла, нужно исправлять.

📊 Фаза 2: Статический анализ

Запускаются плагины для поиска потенциальных багов, стилистических нарушений и плохих практик:

SpotBugs (поиск дефектов)
PMD (проверка кода на антипаттерны)
Checkstyle (контроль стиля)

Пример для Maven: mvn -T 4 spotbugs:check pmd:check checkstyle:check

🧪 Фаза 3: Тесты и покрытие

Выполняются все тесты (юнит + интеграционные), затем генерируется отчёт JaCoCo с порогом покрытия (обычно 80%+).

Юнит-тесты с Mockito: изолированно тестируют сервисы, маскируя зависимости.

Интеграционные тесты с Testcontainers: проверяют взаимодействие с реальной БД (например, PostgreSQL).

API-тесты с MockMvc: тестируют контроллеры в полном Spring-контексте.

🛡️ Фаза 4: Проверка безопасности

Сканирование зависимостей на известные CVE (OWASP Dependency Check).
Поиск секретов в коде и git-истории: пароли, API-ключи (grep + git secrets).
Проверка на типичные уязвимости: System.out.println, вывод exception-сообщений в ответах, wildcard CORS.

🎨 Фаза 5: Линтинг/форматирование (опционально)

Автоматическое форматирование кода с Spotless: mvn spotless:apply или ./gradlew spotlessApply. Этот шаг можно сделать «шлюзом», запрещающим неотформатированный код.

📋 Фаза 6: Diff-ревью

Просмотр изменений (git diff --stat, git diff) с чеклистом:

Нет ли оставленных debug-логов?
Корректные ли HTTP-статусы и сообщения об ошибках?
Есть ли транзакции и валидация там, где нужно?
Описаны ли изменения конфигурации?

🔄 Непрерывный режим

Во время долгой сессии разработки рекомендуется повторять цикл каждые 30–60 минут или после значимых изменений. Короткий цикл (например, только тесты + SpotBugs) даёт быструю обратную связь.

✅ Когда использовать

Перед созданием Pull Request — чтобы не тратить время ревьюверов на очевидные проблемы.
После крупного рефакторинга или обновления зависимостей — для проверки регрессий.
Перед деплоем на staging/production — финальная верификация.
На CI/CD — как pipeline, автоматически запускаемый при пушах.

❗ Важно знать

Цикл рассчитан на проекты с Maven или Gradle, использующие стандартные плагины (SpotBugs, PMD, Checkstyle, JaCoCo, OWASP, Spotless). Если плагин не настроен — соответствующая фаза пропускается.
Покрытие тестами — не панацея, но хороший индикатор. Порог в 80% можно адаптировать под команду.
Быстрая обратная связь — ключевой принцип. Если фаза занимает слишком долго, её можно распараллелить или сделать выборочной.
Инструменты безопасности (grep, git secrets) помогают, но не заменяют SAST-сканеры (например, SonarQube).
Фаза diff-ревью остаётся человеческой: автоматика не заменит внимательного коллеги, но может взять на себя рутину.

📋 Пример итогового отчёта

DOĞRULAMA RAPORU
===================
Build:     [GEÇTİ/BAŞARISIZ]
Static:    [GEÇTİ/BAŞARISIZ] (spotbugs/pmd/checkstyle)
Testler:   [GEÇTİ/BAŞARISIZ] (X/Y geçti, Z% kapsam)
Güvenlik:  [GEÇTİ/BAŞARISIZ] (CVE bulguları: N)
Diff:      [X dosya değişti]

Genel:     [HAZIR / HAZIR DEĞİL]

Düzeltilecek Sorunlar:
1. ...
2. ...

Цикл помогает «держать калитку плотно закрытой» — не пропускать в production даже малые недочёты, которые могут привести к серьёзным инцидентам.

Установка одной командой.

npx skillfish add affaan-m/everything-claude-code springboot-verification

Источник: https://mcpmarket.com/tools/skills/spring-boot-verification-loop-1777750056014