실제 데이터베이스에 대한 단위 테스트 도메인 서비스

Question

다른 사람들이 데이터베이스에 대한 도메인 서비스를 테스트하기 위해 어떤 접근이 가질 수 있는지 궁금해하고 있었습니까? 이미 도메인 서비스 자체를 테스트하기 위해 도메인 서비스에 사용할 수있는 일련의 모의 저장소가 있습니다. 이 모의 저장소 건설의 일부는 샘플 집계 및 관련 엔티티를 구축하고 모델 내에서 사용될 동일한 비즈니스 규칙에 대해 검증한다는 것입니다. 또한 인터페이스가 변경되는 경우 엔티티 내에서 잠재적 인 영향 지점을 감지 할 수있는 멋지고 간단한 수단을 제공합니다.

SQL 지원 저장소의 실시간 테스트에서 볼 수있는 주요 문제는 데이터베이스 일관성입니다. 예를 들어, 테스트가 실행되면 "작성"측면이 이미 실행되었습니다. 데이터베이스가 더 이상 깨끗하지 않기 때문에 다시 실행하면 분명히 실패를 일으킬 수 있습니다. 이 유형의 테스트에만 사용되는 미러링 된 데이터베이스를 작성하는 것을 고려하고있었습니다. 구조, 프로그래밍 가능성, 제약 등을 포함하는 최소화가 최소화됩니다. 또한 특정 설정된 테스트에 대한 최소한의 데이터 세트를 제공합니다. 내 사고 라인은 테스트 실행이 시작되기 전에 기본 데이터가있는 "원시"상태로 데이터베이스를 재설정하기 위해 호출 할 수있는 저장된 절차를 가질 수 있다는 것입니다.

기능이 처음 확인 된 후 개발자 시스템에서는 중요하지 않지만 야간 빌드의 일부로 이러한 테스트를 실행하는 것의 중요성을 더 많이 검토하고 있습니다. 따라서 테스트 실패의 경우 빌드는 대상 배포 환경을 파울하지 않도록 보류 될 수 있습니다 (특히이 경우 테스트 팀이 사용하는 환경이 될 것입니다).

반드시 플랫폼이 중요하다고 생각할 필요는 없지만 누구나 구현 특정 문제가있는 경우 내 환경은 다음과 같습니다.

Windows 7 (개발) / Windows Server 2008 R2 (Server) Visual Studio 2008 Team Edition (C#) Microsoft SQL Server 2008 표준 (개발 / 서버)

팀 빌드를 사용하여 빌드를 실행하고 있지만 이는 질문의 범위에 영향을 미치지 않을 것입니다.

Answer 1

예를 들어, 테스트가 실행되면 "작성"측면이 이미 실행되었습니다. 데이터베이스가 더 이상 깨끗하지 않기 때문에 다시 실행하면 분명히 실패를 일으킬 수 있습니다.

어쩌면 단위 테스트를 트랜잭션으로 만들 수 있습니다. 테스트를 실행하고 롤백하면 데이터베이스가 변경되지 않습니다.

Spring에는 거래를 쉽게 할 수있는 트랜잭션 단위 테스트 클래스가 있습니다. 거래 관리자 만 있으면됩니다.

Answer 2

당신이 사용할 수있는 SQL Server Express (2005 년으로 수행했지만 2008 년에 시도하지 않았습니다) 파일로 저장된 "테스트 데크"데이터베이스를 설정하려고했습니다. 이들은 소스 제어에 체크인 한 다음 테스트 헬퍼 클래스는 (a) 임시 폴더로 복사하고 (b) 쓰기를 참조하고 (c) 연결할 수 있습니다. 원래 상태를 복원하려면 임시 사본을 삭제하고 AC를 반복하십시오.

이것은 큰 고통입니다. Duffymo가 제안한대로 거래를 할 수 있다면 나는 그와 함께 갈 것입니다. 트랜잭션이있는 통증 지점은 중첩 된 거래 및 분산 거래입니다. 코드의 사람들을 조심하십시오.

Answer 3

테스트 코드에서 테스트 실행을 시작할 때 실행되는 테스트 코드에서 많은 데이터 공장을 만들 수 있습니다. 그런 다음 트랜잭션 롤백 방법을 사용하여 깨끗하게 유지하십시오. 쉽게하기 위해 모든 테스트 클래스를 서브 클래스하고 거래 액세서 및 롤백 코드를 거기에 넣으십시오. 롤백 코드는 모든 테스트 방법이 완료되면 자동으로 실행되도록 설정할 수 있습니다.

Answer 4

실제로 데이터베이스에 도달하는 저장소에 대한 단위 테스트를 실행하는 경우 단위 테스트를 수행하지 않습니다. 유용한 테스트 일 수 있지만 단위 테스트는 아닙니다. 그것은 통합 테스트입니다. 그렇게하고 그것을 통합 테스트라고 부르면 완벽하게 괜찮습니다. 그러나 리포지토리에서 좋은 설계 원칙을 따르고 있다면 장치 테스트에서 데이터베이스를 테스트 할 필요가 없습니다.

간단히 말해서, 저장소 장치 테스트는 저장소에 대한 입력을 기반으로 데이터베이스에서 어떤 넓은 효과가 발생하는지 테스트하지 않습니다. 저장소에 대한 입력이 그러한 값과 그러한 값 세트를 가진 공동 작업자에게 호출을 초래한다는 것을 확인하는 것입니다.

코드의 나머지 부분과 마찬가지로 저장소는 단일 보충 가능성 원칙을 따라야합니다. 기본적으로 귀하의 Respoity에는 하나의 보증 가능성이 하나 뿐이며 도메인 모델 API 문제를 기본 데이터 액세스 Technoloy Layer (일반적으로 ADO.NET이지만 엔티티 프레임 워크 또는 L2S 등)에 중재하는 것입니다. ado.net 호출의 예를 들어, 저장소는 데이터 계층의 공장에 대한 책임을지지 않아야하며 대신 ado.net data interfaces (특히 idbconnection/idbcommand/idbparameter의 공동 작업자에 대한 종속성을 취해야합니다. 등). IDBConnection을 생성자 매개 변수로 사용하여 하루를 호출하십시오. 즉, 인터페이스 및 공급 모의 (또는 가짜 또는 스터브 또는 필요한 모든 것을)에 대해 저장소 장치 테스트를 작성하고 예상 입력과 함께 필요한 방법이 순서대로 확인할 수 있습니다. 이 정확한 주제에 대해 내 MS 블로그를 확인하십시오 -> http://blogs.msdn.com/b/schlepticons/archive/2010/07/20/unit-testing-repositories-a-rebuttal.aspx

바라건대 이것은 미래의 테스트와 디자인에서 실수를 저지르는 데 도움이됩니다.

BTW : 데이터베이스를 장치 테스트하려면 가능합니다. Visual Studio 데이터베이스 테스트 만 사용하십시오. VS에 내장되어 있으며 VS2005 이후에있었습니다. 이것은 새로운 것이 아닙니다. 그러나 나는 당신에게주의를 기울여야합니다. 그들은 완전히 단위 테스트가 필요합니다.

Answer 5

코드가 공정하게 데이터베이스 독립적 인 경우, 단위 테스트 용 SQLITE (통합 테스트 아님)와 같은 메모리 데이터베이스를 사용하면 속도와 편의의 이점이 제공됩니다 (테스트 설정은 DB를 초기화).