통합 테스트의 마지막 퍼즐은 프로세스 외부 관리 의존성이다. 가장 일반적인 예시인 데이터베이스를 테스트 하는 방법을 알아보자.
8장에서 살펴봤듯이, 통합 테스트에서는 관리 의존성이 그대로 있어야 한다. 테스트를 작성하기 전에 통합 테스트가 가능하게끔 준비 단계를 수행해야 하는데, 다음과 같은 전제조건을 먼저 살펴보자.
DB를 테스트하는 방법의 첫 단계는 DB 스키마를 일반 코드로 취급하는 것이다. 모든 DB 스키마 업데이트를 형상 관리 시스템(ex: Git)에 두면 원천 정보를 하나로 할 수 있고, 일반 코드 변경과 함께 DB 변경을 추적할 수 있다.
<aside> 💡 참조 데이터 : 애플리케이션이 제대로 작동하도록 미리 채워야 하는 데이터
</aside>
DB 스키마라면 자주 거론되는 대상은 테이블, 뷰, 인덱스, 저장 프로시저 그리고 나머지 모든 것이다. 스키마는 SQL 스크립트 형태로 표현된다. 하지만 참조 데이터는 DB 스키마에 속하지만, DB 스키마로 거의 여기지 않는다.
이전 장의 CRM 시스템에서, 사용자 타입은 Customer 또는 Employee 일 수 있었다. 모든 사용자 타입이 포함된 테이블을 만들고 User에서 해당 테이블로 외래 키 제약을 두고 싶다고 가정해보자. 이런 조건을 통해 애플리케이션이 사용자에게 존재하지 않는 타입을 할당하지 않게끔 보증할 수 있다. 이 시나리오에서 UserType 테이블의 내용이 참조 데이터에 해당한다.
<aside> 💡 애플리케이션이 데이터를 수정할 수 있으면 일반 데이터고, 그렇지 않으면 참조 데이터다.
</aside>
참조 데이터는 애플리케이션의 필수 사항이므로, 다른 DB 스키마와 함께 SQL INSERT 문 형태로 형상 관리 시스템에 저장해야 한다.
실제 DB로 테스트하는 것은 어렵다. 다른 개발자들과 DB를 공유해야 한다면 더 어렵다. 서로 다른 개발자가 실행한 테스트가 간섭되기도 하고, 하위 호환성이 없는 변경으로 다른 개발자의 작업을 막을 수도 있다. 테스트 실행 속도를 극대화하려면 개발자마다 별도로 DB 인스턴스를 사용하라.