데이터베이스 스키마를 소스 코드와 같이 형상 관리 시스템에 저장하라. 테이블, 뷰, 인덱스, 저장 프로시저와 데이터베이스 구성방식에 대한 청사진이 되는 기타 모든 항목 등이 데이터베이스 스키마에 해당한다.
참조 데이터도 데이터베이스 스키마에 해당한다. 이는 애플리케이션이 제대로 작동하도록 미리 채워져야 하는 데이터다. 참조 데이터와 일반 데이터를 구별하려면 애플리케이션에서 해당 데이터를 수정할 수 있는지 확인하면 된다. 수정할 수 있으면 일반데이터이고, 그렇지 않으면 참조 데이터이다.
개발자마다 데이터베이스 인스턴스를 별도로 두게 하라.
상태 기반 데이터베이스 배포 방식은 상태를 명시적으로 만들고 비교 도구가 마이그레이션을 암묵적으로 제어할 수 있도록 한다. 마이그레이션 기반 방식은 데이터베이스를 특정 상태에서 다른 상태로 전환하게끔 명시적 마이그레이션을 사용하도록 한다.
상태 기반 방식보다는 마이그레이션 기반 방식을 선호한다. 데이터 모션처리가 병합 충돌보다 훨씬 중요하기 때문이다. 마이그레이션을 통해 모든 수정사항을 데이터베이스 스키마에 적용하라.
비즈니스 연산은 데이터를 원자적으로 업데이트해야 한다. 원자성을 얻으려면 데이터베이스 트랜잭션 매커니즘에 의존하라.
가능하면 작업 단위 패턴을 사용하라. 작업 단위 패턴은 데이터베이스 트랜잭션에 의존하며, 비즈니스 연산 종료 시점까지 업데이트를 모두 지연시켜서 성능을 향상시킨다.
테스트 구절마다 데이터베이스 트랜잭션이나 작업단위를 재사용하지 말라. 준비, 실행, 검증 구절에 각각 고유의 트랜잭션이나 작업 단위가 있어야 한다.
통합 테스트는 순차적으로 실행하라. 병렬 실행에는 상당한 노력이 필요하며, 보통 그럴 가치가 없다.
테스트 시작 지점에 남은 데이터를 정리하라. 이 방법은 빠르고 일관성 없는 동작을 일으키지 않으며, 정리 단계를 실수로 건너뛰지 않는다. 이렇게 하면 별도의 종료단계도 둘 필요가 없다.
SQLite 같은 인메모리 데이터베이스는 사용하지 말라. 다른 업체의 데이터베이스로 테스트를 실행하면 보호 수준이 떨어진다. 테스트에서도 운영 환경과 같이 동일한 DBMS를 사용하라.
필수가 아닌 부분을 비공개 메서드 또는 헬퍼 클래스로 추출해 테스트를 단축하라.
준비 구절에서는 테스트 데이터 빌더 대신 오브젝트 마더를 선택하라.
실행 구절에서는 데코레이터 메서드를 작성하라.
검증구절에서는 플루언트 인터페이스를 도입하라.
읽기 테스트 임계치는 쓰기 테스트보다 높아야 한다. 가장 복잡하거나 중요한 읽기 작업만 테스트하라. 나머지는 무시하라.
리포지터리는 직접 테스트하지 말고 포괄적인 통합 테스트 스위트로 취급하라. 리포지터리 테스트는 회귀 방지에 대한 이득이 너무 적은 데 반해 유지비가 너무 높다.
