확실히 누군가가 내 좌절감을 덜어주기를 바랍니다. WCF 서비스 구현 클래스를 단위 테스트 할 수있는 좋은 방법을 찾으려고 노력하고 있지만 솔루션을 제공한다는 것을 알게 된 모든 리소스는 단일 메서드/작업만으로 서비스로 제한됩니다.여러 종속성이있는 WCF 서비스 단위 테스트
제 경우에는 몇 가지 서비스 메소드/연산을 포함하는 서비스 클래스가 있습니다. 서비스 클래스의 목적은 핵심 응용 프로그램 내에서 구현되는 비헤이비어에 인터페이스를 제공하는 것입니다.
- 가 이 작업을 수행하는 적용 명령 개체의 인스턴스를 생성하는 개체의 속성
- 확인하는 발신자
- 에서 Request 객체를 받아들이 : 위해 이와 같이, 각각의 방법/작업을 담당한다
- 요청 개체의 속성을 Command 개체에 매핑합니다. 명령을 실행 호출자 또한
에 대한 응답을 반환하는 응답 객체
우리는 IoC (DI)와 AOP 모두 Spring.NET을 사용하고 있습니다. 서비스 클래스는 Spring에 의해 인스턴스화되어 Spring의 ParameterValidation aspect를 사용하여 2 단계를 수행하게합니다. 기본적으로 3 단계에서 Spring을 사용합니다.
대부분이 모든 것이 효과적입니다. 그러나 서비스 메소드의 동작을 확인하기위한 유닛 테스트를 작성할 때 여러 메소드 객체 (메소드 당 하나)에 대한 서비스의 종속성을 처리하는 올바른 방법을 파악하기가 어려워졌습니다.
Command 객체를 조롱하는 데 문제가 없으며 (우리는 Moq, btw를 사용함) 문제가 없으며 블랙 박스 테스트를 수행하는 데 문제가 없음을 분명히 알겠습니다. 4 단계가 올바르게 수행되었는지 확인하거나 Command 개체가 예외를 throw하는 경우 서비스가 올바르게 처리하는지 확인하는 등 내부 논리에 대한 흰색 상자 테스트를 수행하려고합니다. 이들을 위해 Command 객체의 mock 인스턴스를 사용하고 있습니다.
문제는 테스트 대상 개체가 여러 종속성을 갖는 시나리오에 대한 모범 사례를 찾는 것입니다. 특히 실행중인 테스트에 대해 그 중 하나에만 관심이있는 경우 특히 그렇습니다.
DI에 대한 생성자 접근 방식은 서비스에서 메서드를 수행 할 때 생성자에 대한 인수를 많이 가질 필요가 있으므로 실용적이지 않습니다. 세터 주입은 세터가 테스트 목적으로 만 존재할 것이기 때문에 걱정스럽고, 많은 경우에 세터 주입이 많을 것이기 때문입니다.
이 서비스는 4 단계를 기본적으로 Spring을 사용하여 Command 개체를 인스턴스화하지만 상속 및 재정의 방식을 사용하여 모의을 반환하도록 재정의되는 가상 메서드로 위임하도록 설계되었습니다. 그러나 이것은 다루기 힘든 것으로 판명되었습니다.
그래서 다양한 솔루션을 선보이는 온라인 기사 다음에 기사를 쏟아 부은 후, 내가 말했듯이 한 가지 방법/작업으로 서비스를 반영하는 것만으로도 쉽게 구현할 수있는 방법에 대한 지침을 찾고 있습니다. 여러 메소드와 여러 종속성을 포함하는 실제 서비스를 처리 할 때 유지 보수하고 확장하십시오.
mocked Command 객체를 삽입하기 위해 Spring을 사용할 수 없다는 것을 명심하십시오. mock을 설정하고 메소드의 동작을 검증하기 위해 mock에 대한 참조가 필요하기 때문입니다. (내 테스트가 제대로 작동하는 스프링에 의존한다는 것은 말할 것도 없습니다.)
마지막 공연에서 우리는 자기 호스팅 서비스에 조롱을 삽입하는 방법을 알아 냈습니다. "단위 테스트"(이 단계의 수용 테스트 더)는 테스트중인 서비스를 호출하는 경량 클라이언트를 호출했습니다. 이것이 당신의 필요에 맞는 것이라면 내가 코드를 파고 게시 할 수 있는지 알게 될 것입니다. –
우리가 찾고있는 것보다 기능 테스트와 비슷합니다. 사실, 서비스 클래스 구현을 "단위"로 테스트하려고한다는 것을보다 분명하게 지적 했어야합니다. 이 시점에서 WCF조차 사용하지 않습니다. – SonOfPirate