Spring Boot 조회 경로 정책¶

기존 데이터베이스 테스트로 SELECT 상한과 INSERT/UPDATE/DELETE 0개를 강제해 봐요. 스타터가 Spring DataSource를 감싸요. 아래 코드는 가장 최근에 공개된 릴리스를 써요.

스타터 추가하기¶

테스트 의존성을 복사하세요. 예산과 개수 계약만 쓴다면 스타터로 충분해요. 인덱스나 EXPLAIN 검사가 필요할 때 데이터베이스 모듈을 추가하세요.

통제된 첫 감사 실행하기¶

애플리케이션의 테스트 패키지에 QueryAuditInstallationTest.java를 만들어요. 아래 import 위에 패키지 선언을 추가하세요.

import static org.junit.jupiter.api.Assertions.assertEquals;

import io.queryaudit.junit5.EnableQueryInspector;
import io.queryaudit.junit5.ExpectQueries;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.jdbc.core.JdbcTemplate;

@SpringBootTest
@EnableQueryInspector
class QueryAuditInstallationTest {

    @Autowired
    private JdbcTemplate jdbc;

    @Test
    @ExpectQueries(select = 0, insert = 0, update = 0, delete = 0)
    void capturesOneSelect() {
        assertEquals(1, jdbc.queryForObject("select 1", Integer.class));
    }
}

이 테스트만 실행해요.

./gradlew test --tests '*QueryAuditInstallationTest'

mvn -Dtest=QueryAuditInstallationTest test

기대하는 실패:

QueryAudit: capturesOneSelect() exceeded its query budget.
SELECT: executed 1, expected at most 0.

select = 0을 select = 1로 바꾸고 다시 실행하면 테스트가 통과해야 해요. 예산 0으로 돌렸는데도 통과하면 캡처 점검 목록을 따라가세요.

기존 조회 테스트에 정책 적용하기¶

기능 단언은 그대로 두고, 다음 어노테이션을 직접 붙여요.

@EnableQueryInspector
@ExpectQueries(select = 1, insert = 0, update = 0, delete = 0)

SELECT 상한은 그 서비스나 리포지토리 작업에 맞게 정하세요. 변경 때문에 UPDATE가 추가되면, 기능 단언이 여전히 통과하더라도 정책이 실패해요.

UPDATE: executed 1, expected at most 0.

@EnableQueryInspector는 탐지 결과를 보고만 하고, 명시한 예산은 여전히 단언으로 동작해요. 통과를 믿기 전에 실제 작업으로 일부러 위반을 만들어 확인하세요. 실행 가능한 예제에서 쓰기 추가와 SELECT 추가 실패를 직접 볼 수 있어요.

결과 확인하기¶

활성 테스트 프로필, 예를 들어 src/test/resources/application.yml에 다음을 추가해요.

query-audit:
  report:
    format: json

build/reports/query-audit/report.json을 열어요.

테스트가 여러 개라면 쿼리 수를 계약 파일에 기록하고 의도한 변경은 diff로 리뷰하세요. CI에서 완전한 결과를 요구하고, 커버리지와 비교 검사로 빠진 테스트나 바뀐 감사 설정이 드러나게 하세요.

선택 설정¶

기본값과 덮어쓰기는 설정을 보세요. JSON/Actions 마스킹은 현재 콘솔과 HTML 진단에는 적용되지 않아요. 리포트 개인정보를 참고하세요.

DataSource 캡처 방식¶

스타터는 Spring DataSource 빈을 감싸요. JUnit 확장은 실행 중인 테스트의 캡처 리스너를 선택된 쿼리 인식 데이터소스에 연결해요. 애플리케이션 SQL은 감사 구간 동안 바로 그 객체를 거쳐야 해요.

데이터소스가 여러 개라면 감사 대상 코드가 쓰는 것을 보통 @Primary로 분명히 하세요. 그렇다고 모든 데이터소스가 하나의 감사로 합쳐지는 건 아니에요. 데이터소스가 여러 개인 애플리케이션에서는 실제 리포지토리 경로로 캡처를 증명하세요.

기존 datasource-proxy 재사용하기¶

다른 라이브러리가 이미 쿼리를 인식하는 Spring 데이터소스를 제공한다면, 스타터의 추가 감싸기만 끄세요.

query-audit:
  wrap-data-source:
    enabled: false

QueryAudit은 켠 상태로 두세요. 확장이 기존 datasource-proxy에 연결되고, 별도 인터셉터 빈은 필요 없어요. 컨텍스트에 원본 데이터소스만 있다면 자동 감싸기를 켠 채로 두세요. 이 설정을 바꾼 뒤에는 SELECT 1개와 예산 0으로 실패하는지 다시 확인하세요.

스위트 전체 감사하기¶

junit.jupiter.extensions.autodetection.enabled=true

query-audit:
  mode: all
  profile: recommended

QueryAudit 끄기¶

query-audit.enabled: false는 감사 없이 실행하려는 경우에만 쓰세요. 잠시 보고만 하고 싶다면 켠 채로 @EnableQueryInspector를 쓰세요. 명시한 예산은 여전히 단언으로 동작해요.

다음 단계¶

• 테스트별 쿼리 수 변경 리뷰하기
• 감사할 테스트를 요구하고 CI 결과 비교하기
• 증상별 첫 확인 사항 찾기