나는 "그것이 달려있다"고 확신하기 때문에 농담으로 질문의 제목을 붙 였지만, 몇 가지 구체적인 질문이 있습니다.
많은 계층의 종속성이있는 소프트웨어에서 작업하면서 팀은 각 코드 모듈을 그 아래의 종속성과 분리하기 위해 상당히 광범위하게 조롱하는 데 익숙해졌습니다.
따라서 Roy Osherove 가이 비디오 에서 5 % 정도의 조롱을 사용해야한다고 제안한 것에 놀랐습니다 . 우리가 70-90 % 사이에 있다고 생각합니다. 나는 때때로 다른 유사한 지침 을 보았습니다 .
나는 서로 다른 이름을 부여해야 할 두 가지 범주의 "통합 테스트"로 간주되는 것을 정의해야한다. 1) 여러 코드 모듈을 통합하는 In-process 테스트 및 2) 말하는 Out-of-process 테스트 데이터베이스, 파일 시스템, 웹 서비스 등에 관심이 있습니다. 모든 프로세스에서 여러 코드 모듈을 통합하는 테스트입니다.
내가 읽은 많은 커뮤니티 지침에 따르면 단위 테스트는 정확한 위치에 대한 정확한 피드백을 제공하기 때문에 많은 수의 분리 된 세밀한 단위 테스트와 소수의 거친 세분화 된 통합 테스트를 선호해야합니다. 회귀가 생성되었을 수 있지만 설정하기가 까다로운 거친 테스트는 실제로 시스템의 더 많은 기능을 검증합니다.
이를 감안할 때 이러한 별도의 코드 단위를 분리하기 위해 조롱을 자주 사용하는 것이 필요합니다.
다음과 같은 객체 모델이 제공됩니다.
... 또한 응용 프로그램의 종속성 깊이가이 이미지에 맞을 수있는 것보다 훨씬 더 깊어 2-4 레이어와 5-13 레이어 사이에 다중 레이어 N이 있다고 생각하십시오.
유닛 # 1에서 수행되는 간단한 논리적 결정을 테스트하고 모든 의존성이 코드 모듈에 생성자 주입되는 경우, 예를 들어 2, 3 및 4는 생성자 모듈 1에 생성자 주입됩니다. 이미지, 나는 오히려 2, 3 및 4의 모형을 1에 주입합니다.
그렇지 않으면 2, 3 및 4의 구체적인 인스턴스를 구성해야합니다. 이는 추가 타이핑보다 더 어려울 수 있습니다. 종종 2, 3 및 4는 만족스럽고 그래프에 따라 (그리고 프로젝트의 현실에 따라) 생성자 요구 사항을 갖습니다. 2, 3 및 4.
2, 3 또는 4가 특정 방식으로 작동해야 # 1의 간단한 논리적 결정을 테스트 할 수있을 때 이러한 상황이 더욱 어려워집니다. 2, 3 또는 4가 필요한 방식으로 작동하려면 전체 객체 그래프 / 트리를 한 번에 이해하고 "정신적으로 추론"해야 할 수도 있습니다. myMockOfModule2.Setup (x => x.GoLeftOrRight ()). Returns (new Right ());를 수행하는 것이 훨씬 쉬운 것 같습니다. 모듈 2가 올바른 방향으로 지시하면 모듈 1이 예상대로 응답하는지 테스트합니다.
2 ... N ... 13의 구체적인 인스턴스를 모두 함께 테스트하려면 테스트 설정이 매우 커서 대부분 복제됩니다. 테스트 실패는 회귀 실패의 위치를 정확히 찾아내는 데 도움이되지 않을 수 있습니다. 테스트는 독립적 이지 않습니다 ( 다른 지원 링크 ).
물론 하위 계층에 대한 상호 작용 기반 테스트보다는 상태 기반 테스트를 수행하는 것이 합리적입니다. 이러한 모듈은 더 이상 의존성이 거의 없기 때문입니다. 그러나 가장 아래의 모든 모듈을 분리하려면 정의에 따라 조롱이 거의 필요합니다.
이 모든 것을 감안할 때, 내가 잃어버린 것을 말해 줄 수 있습니까? 우리 팀이 모의를 과용합니까? 또는 일반적인 단위 테스트 지침에서 대부분의 응용 프로그램의 종속성 계층이 함께 통합되어 모든 코드 모듈을 함께 테스트하는 것이 합리적이라고 가정합니다 (사례를 "특별한")? 아니면 다르게는, 우리 팀이 우리의 경계 컨텍스트를 적절하게 묶지 않습니까?
Or is there perhaps some assumption in typical unit testing guidance that the layers of dependency in most applications will be shallow enough that it is indeed reasonable to test all of the code modules integrated together (making our case "special")? <-이것.