콘텐츠로 이동
Bluetape4k 문서1.11

테스트·운영·생태계 경로

최신 안정판 Bluetape4k 1.11.0 릴리스 기준

테스트 책임은 실제 client에 있다

섹션 제목: “테스트 책임은 실제 client에 있다”

infra/redis에는 production source와 test source가 없습니다. 그래서 :bluetape4k-redis:test가 성공해도 두 client의 연결, coroutine, Codec이나 분산 객체 동작을 검증했다는 뜻은 아닙니다. 사용한 하위 모듈의 테스트와 애플리케이션 통합 테스트를 실행해야 합니다.

Terminal window
./gradlew :bluetape4k-lettuce:test --no-build-cache --no-configuration-cache
./gradlew :bluetape4k-redisson:test --no-build-cache --no-configuration-cache

두 suite는 실제 Redis를 Testcontainers로 띄웁니다. 다른 DB·broker Testcontainers suite와 병렬 실행하지 않습니다. 이 매뉴얼처럼 문서만 바꿀 때는 heavy suite 대신 배포 source link, locale 구조와 Markdown 검증을 실행합니다.

배우려는 계약대표 테스트
Lettuce client·cached connection·shutdownLettuceClientsTest.kt
RedisFuture 결과·실패 전달RedisFutureSupportTest.kt
Redisson client 구성·batch·transactionRedissonClientSupportTest.kt
Stream group·consumer helperRStreamSupportTest.kt

우산 모듈 자체 예제처럼 묶어 설명하지 않고, 실제 소유 module의 테스트에서 API와 실패 조건을 읽습니다.

두 client를 함께 운용한다면 metrics도 합산하지 말고 client별로 구분합니다.

  • connection·pool 사용량과 reconnect
  • command latency, timeout과 retry
  • pending async 작업과 coroutine cancellation
  • Codec decode 실패와 key prefix별 schema version
  • Redisson Stream pending entry와 Near Cache stale incident
  • shutdown 시간과 처리하지 못한 queue

우산 모듈을 선택 의존성으로 줄인 뒤에는 제거한 client의 thread, connection과 metric이 실제로 사라졌는지 확인합니다.

  1. client와 command가 필요하면 Lettuce 매뉴얼 또는 Redisson 매뉴얼을 끝까지 읽습니다.
  2. 공통 cache 정책이 필요하면 Cache Core에서 cache-aside와 failure 계약을 먼저 익힙니다.
  3. provider 구현은 Lettuce CacheRedisson Cache로 이어갑니다.
  4. Hibernate 2차 cache는 Hibernate Cache Lettuce에서 region과 transaction 경계를 확인합니다.
  5. database repository와 cache를 함께 다루는 실습은 Exposed Workshopbluetape4k-workshop에서 진행합니다.

우산 모듈은 이 경로의 기능 계층이 아니라 두 client를 함께 가져오는 build 편의 계층입니다. 학습과 운영은 실제로 선택한 client와 cache provider를 기준으로 나눕니다.