인 컨테이너 테스트는 종종 모의 객체로 테스트하는 것에 반대합니다. 그러나 모의 객체가 단순히 실제 객체의 동작을 모방하기 때문에 실제 환경에서 시스템을 실제로 테스트하는 유일한 방법은 인 - 컨테이너 테스트가 아닌가?인 컨테이너 테스트와 모의 객체 대 통합 테스트
컨테이너 내 테스트 및 모의 객체의 부분적인 대안으로 Spring은 실제 응용 프로그램 컨테이너 (필자의 경우 웹 응용 프로그램 서버)를 시작하지 않고도 Spring을 멋지게 초기화하는 TestContext 프레임 워크를 제공합니다. 그러나 이는 애플리케이션 서버 고유의 기능이 지원되지 않는 동안 Spring 고유의 기능 만 초기화하기 때문에 다소 제한적인 접근 방식이다. 그래서 모든 것을 테스트 할 수는 없습니다. 또한 실제 웹 실행에 사용되는 기본값 인 WebApplicationContext과 100 % 동일하지 않기 때문에이 방법이 조금 해킹되지 않습니까? 나쁜가요?
컨테이너 내 테스트의 경우 Cactus (구형), Jeeunit (매우 작은 프로젝트) 및 JBoss Arquillian (여전히 알파이지만 유망 해 보입니다)이 있습니다. 이 프로젝트가 너무 광범위하게 사용되는 것을 보지 못했기 때문에 용기 내 테스트에 문제가 있습니까? 컨테이너 내 테스트에서 자주 언급되는 주된 단점은 실행 속도가 느리다는 것입니다. 그러나 지속적인 통합 환경과 비교적 작은 규모의 프로젝트에서 실행될 때는 문제가되지 않습니다.
정리 요약 : 컨테이너 내 또는 컨테이너 외부 테스트를해야하며 그 이유는 무엇입니까? 모의 객체 나 다른 초기화 메카니즘 (Spring TestContext와 같은)을 사용하여 통합 테스트를 수행하는 것이 좋지 않습니까?
부제 : 나는 최근에 약 categorization of integration test에 대해 물었습니다.
컨테이너에서 단위 테스트를 완벽하게 실행하고 있습니다. 사실, "스프링 배선"을 테스트하기 위해 왜 "작은 컨테이너 내 단위 테스트"를 실행하는지 이해할 수 없습니까? 어쩌면 거기에 타이포그래피, "작은 컨테이너 내 통합 테스트 *"를 의미할까요? 또한 올바르게 이해합니까? 런타임 구성이 변경되면 해당 설정을 통합 테스트 프로젝트에 복사해야합니까? 컨테이너 내 테스트를 실제로 어떻게 실행/초기화합니까? 어쩌면 일부 프레임 워크의 도움으로? –
섹션을 편집했습니다. 우리는 모든 스프링 배선이 작동하는지 확인하기 위해 단위 테스트 모음에서 몇 가지 통합 테스트를 수행해야한다는 것을 의미했습니다. 모든 구성 파일은 코드와 함께 있습니다. 통합 프로젝트에 구성을 복사하지 않습니다. 통합 프로젝트는 프로덕션 코드와 동일한 패키지 경로를 공유하므로 동일한 src/main/resource (우리는 mvn을 사용하고 있습니다) 구성을 모두로드 할 수 있습니다. – Gray