데이터베이스 테스트

실제 DB를 테스트에서 쓴다는 건 그냥 연결만 한다는 게 아니야. 어떻게 관리할 것인지, 어떻게 격리할 것인지를 제대로 설계해야 해. 10장은 DB 테스트를 잘 하는 방법이야.

먼저 전제 조건부터. 개발자마다 자신만의 DB 인스턴스가 있어야 해. 공유 DB에서 테스트하면 테스트 간 간섭이 생겨. 내가 만든 데이터가 다른 사람 테스트를 깨트릴 수 있거든. 그리고 테스트는 반복 실행 가능해야 해. 실행 전후 상태가 동일해야 한다는 거야.

DB 스키마 관리 방식은 두 가지야. **상태 기반(State-based)**은 원하는 DB 상태를 정의하고 차이를 비교해서 마이그레이션을 자동 생성해. **마이그레이션 기반(Migration-based)**은 변경 이력을 스크립트로 관리해. Flyway, Liquibase 같은 게 여기 해당돼. 저자는 마이그레이션 기반을 선호해. 변경 이력이 명시적으로 남고, 프로덕션 환경과 동일한 방식으로 스키마를 관리할 수 있거든.

테스트마다 DB 상태가 영향을 받으면 안 돼. 격리 전략이 필요해. 트랜잭션 롤백으로 처리하는 방법은 빠르지만 실제 트랜잭션 동작을 테스트하기 어려워. 저자는 테스트 후 데이터 삭제 또는 테스트 전 초기화 방식을 권장해. 설정이 복잡하지만 실제 환경에 가장 가깝거든.

통합 테스트는 Arrange 섹션이 길어지기 쉬워. 공통 준비 코드를 재사용하는 방법으로 Object Mother 패턴이나 Test Data Builder가 있어. 단, 재사용이 과도해지면 테스트가 자기 완결적이지 않게 돼. 테스트를 읽을 때 어떤 데이터가 준비됐는지 한눈에 보여야 해. 헬퍼에 너무 많이 숨기면 테스트를 이해하기 위해 여러 파일을 뒤져야 하거든.

---

정리

10장 읽고 기억할 거 세 가지:

1. 실제 DB를 써: 개발자별 독립 DB 인스턴스로 테스트 간 간섭 없이 실제 환경에 가깝게 검증
2. 마이그레이션 기반 스키마 관리: 변경 이력이 코드에 남고, 프로덕션과 동일한 방식으로 관리돼
3. 테스트 격리는 필수: 테스트가 서로 영향을 주면 안 돼. 실행 전후 상태를 항상 깨끗하게