단위 테스트 규칙

Question

내 질문은 당신의 일부 정말 바보 나타날 수 있지만 미안 .. 물어 봐야은 ... .. 당신은 어떻게 당신의 비즈니스 클래스를 테스트 할 수 있습니다 데이터베이스를 수정하지 않고 클래스 또는 데이터 액세스 레이어를 사용할 수 있습니까? 데이터베이스의 필드를 업데이트하는 기능이 있습니다. 아무 것도 놀라워요 .. 비즈니스 계층 클래스가 인스턴스화되고 BLL.Update() 메서드가 일부 컨트롤을 만들고 마지막으로 DAL 클래스를 인스턴스화하여 저장된 프로 시저를 올바른 매개 변수로 데이터베이스에 저장하십시오.

그것의 작동하지만 내 질문은 ...

내가 시험에 데이터베이스에 영향을 가지고있는 DALayer 클래스를 테스트 단위 테스트를 수행합니다! 예를 들어, 값 5가 데이터베이스에 잘 전달되면 테스트를 수행해야합니다. 테스트를 마친 후에 데이터베이스 필드는 5가됩니다.

그래서 난 .. 답변 .. 내가없는 방법을 실행하지 않고 당신이 테스트를 할 수있는 방법을 이해하지 않아도 일반적으로 시스템이 시험에 의해 영향을받지

송신을 알고 불쌍한 내 영어 변명

Answer 1

질문을 여러 가지 하위 질문으로 나눌 것입니다. 왜냐하면 함께 답하기가 어렵 기 때문입니다.

단위 테스트 X 통합 테스트

당신이 단위 테스트는 테스트하는 간단한 장치를 작성합니다. 즉, 테스트 된 메소드에서 단일 실행 경로를 테스트하는 것입니다. 언급 된 데이터베이스와 같은 종속성을 테스트하지 않아야합니다. 일반적으로 각 실행 경로마다 간단한 단위 테스트를 작성하여 테스트를 통해 코드 커버리지를 높입니다.

통합 테스트를 작성할 때 모든 레이어를 테스트하여 통합 및 구성이 작동하는지 확인합니다. 일반적으로 모든 실행 경로에 대한 통합 테스트는 작성하지 않습니다. 모든 조합을 여러 계층에 걸쳐서 수행하기 때문입니다.

테스트 비즈니스 클래스 - 단위 테스트 당신은 DAL 및 DB에 의존하지 않고 비즈니스 클래스를 테스트 할 필요가

. 그렇게하기 위해서는 BL 클래스를 디자인해야만 그 의존성이 외부에서 주입 될 수 있습니다. 먼저 DAL에 대한 추상 클래스 또는 인터페이스를 정의하고 해당 DAL 인터페이스를 생성자에 대한 매개 변수로 전달해야합니다 (다른 방법은 BL 클래스의 setable 속성을 노출하는 것입니다). BL 클래스를 테스트 할 때 DB에 의존하지 않는 다른 DAL 인터페이스 구현을 사용하게됩니다. 이러한 더미 구현을 생성하고 사용하는 방법을 정의하는 잘 알려진 테스트 패턴 Mock, Stub 및 Fake가 있습니다. 조롱은 또한 많은 테스트 프레임 워크에서 지원됩니다.

테스트 데이터 액세스 계층 - 통합 테스트 당신은 실제 DB에 대한 귀하의 DAL를 테스트 할 필요가

. 테스트 데이터 세트로 테스트 DB를 준비하고 해당 데이터로 작업 할 테스트를 작성합니다.각 테스트는 자체 트랜잭션에서 실행될 것이며, 트랜잭션은 끝에 롤백 될 것이므로 초기 데이터 세트를 수정하지 않을 것입니다.

안부, 라디

Answer 2

db 상호 작용 측면에서 설명하는 시나리오의 경우 조롱이 유용합니다. 기회가 있다면 Rhino Mocks

Answer 3

Inversion of Control을 조롱 프레임 워크와 함께 사용하십시오. 이미 언급 한 사람처럼 Rhino가 겁을냅니다.

Answer 4

당신이 조롱하고는 평신도 측면에서 통합 테스트 될 것입니다 테스트에서 실제 DB를 사용에 의존하지 않는 그것은 더 이상 단위 테스트 아니라면. 나는 전용 SQL .mdf가 [Setup]의 [Setup] 부분에서 NUnit을 사용하는 데이터베이스 서버에 첨부 된 소스 컨트롤에 있었고, [TearDown]에서는 분리 된 프로젝트에서 작업했습니다. 이 작업은 NUnit 테스트가 수행 될 때마다 수행되었으며 SQL 코드에 따라 시간이 많이 소요될 수 있으며 데이터 크기가 더욱 악화 될 수 있습니다.

캐치가 유지 관리 오버 헤드이며, 스프린트주기 및 relaease 중에 DB scehma를 변경할 수 있습니다. 변경 DB 스크립트는 통합 테스트에 사용 된 것을 포함하여 개발 및 테스트에 사용 된 모든 데이터베이스에서 실행되어야합니다 상술 한 바와 같이. 뿐만 아니라, 새로운 테스트 데이터 (위에서 언급 한 사람)가 생성 된 새로운 테이블/열에 대해서는 반드시 popoulate되어야하며, 마찬가지로 요구 사항 변경이나 버그 수정으로 기존 데이터를 정리해야 할 수도 있습니다.

이것은 자체적 인 작업 인 것처럼 보이며 팀에서 유능한 사람이 소유권을 가질 수 있습니다. 또는 이미 구현 한 경우 지속적인 변경의 실행으로 시간 변경 스크립트 실행을 통합 할 수 있습니다. 테스트 데이터의 추가 및 클렌징은 수동으로 처리해야합니다.