데이터베이스 중심 테스트 스위트 유지 보수

Question

데이터베이스 중심 서비스를위한 자동화 된 단위 테스트 스위트를 고려하십시오. 많은 소규모 부품은 데이터베이스 연결없이 단위 테스트가 가능하지만 실제 데이터베이스 스냅 샷 (또는 스냅 샷)을 플러그인하고 더 큰 통합 시나리오를 실행할 수있는 것도 유용합니다. 따라서 일부 주요 테스트에는 테스트 코드 자체와 별도로 사전 실행 및 사후 실행 데이터 스냅 샷의 형태가 포함됩니다.

서비스가 빠르게 발전하고 데이터베이스 스키마도 발전합니다. 이는 테스트 데이터를 끊임없이 무효화하고 결함이있는 동작을 업데이트 된 스냅 샷에 넣지 않고 개발자가 테스트 스위트를 최신 상태로 유지하는 것이 어려워집니다.

일반적으로 이전 (테스트 데이터베이스) 스키마에 대해 새로운 버전의 서비스를 실행할 수 없습니다. 이는 초기화 (테스트 입력) 및 순전히 점검 (예 : 예상 테스트 출력)을 위해 사용되는 데이터베이스 스냅 샷의 두 가지 레이어를 가짐으로써 해결할 수 있습니다. 초기화 스키마/데이터는 응용 프로그램과 함께 자동으로 업그레이드 될 수 있지만 예상되는 출력 데이터는 아닙니다.

나는 몇 번이나이 글을 읽었지만, 사람들의 경험, 기술 및 방법론, 특히 자바, .NET 및 순수 데이터베이스 환경의 맥락에서 주제에 대한 더 많은 정보를 얻을 수있는 링크를 제공해 주시면 감사하겠습니다. .

이 질문은 내가 그것에서 배울 것을 모르기 때문에 의도적으로 다소 광범위하지만, 여기 또한 좁은 버전 :

을 만드는 어떤 널리 사용되는 Java 또는 .NET 프레임 워크가 있습니까 개발자가 동작 (데이터) 차이와 스키마 차이를 쉽게 알 수 있고 기존 테스트 데이터를 새 스키마로 반자동으로 쉽게 업데이트 할 수 있습니까?

Answer 1

1. 그것은 오히려 데이터베이스 변경을 모니터링 프레임 워크를하는 것보다 테스트 스위트의 구성의 문제입니다. 예를 들어, Hibernate/EJB 영속성 모델을 사용한다면, 테스트 스위트를 실행하기 전에 Hbm2Ddl을 사용하여 객체 매핑으로부터 데이터베이스를 생성 할 수 있습니다. 그런 다음 각 테스트는 엔티티를 저장하여 (즉 직접 SQL을 사용하지 않고) 필요한 객체를 만듭니다. 기본적으로이 경우 응용 프로그램의 지속성 계층을 통해서만 데이터베이스를 직접 처리하지 않습니다. 실행이 끝나면 데이터베이스 스키마가 삭제됩니다.

2. 한편으로는 프로세스의 문제입니다. 모든 데이터베이스 변경은 테스트 무결성을 유지해야합니다. 어떤 사람들은 테스트 무결성을 돌보지 않고 데이터베이스를 변경하는 것과는 다릅니다. 기본적으로 코드 나 데이터베이스 구조의 변경과 상관없이 테스트가 중단되면 소스의 변경 사항을 허용해서는 안됩니다. 환언

개발 과정 + 적절한 테스트 환경에서 특정 분야 위 (지속성 층을 통해 작업 설정이 있어야한다, 즉하지 않고 테스트를 제조 데이터베이스의 덤프 인 테스트 데이터베이스 또는 최소한의 설정/해체로).