단위 테스트 대 스프링과의 통합 테스트

StackOverflow https://stackoverflow.com/questions/281758

문제

Spring MVC 프로젝트를 진행하고 있으며 소스 트리의 모든 다양한 구성 요소에 대한 단위 테스트가 있습니다.

예를 들어 컨트롤러가있는 경우 HomeController, 필요한 것은 필요합니다 LoginService 그것에 주입 한 다음 내 단위 테스트에서 HomeControllerTest 나는 단순히 물체를 정상 (봄 외부)으로 인스턴스화하고 속성을 주입합니다.

protected void setUp() throws Exception {
    super.setUp();
    //...
    controller = new HomeController();
    controller.setLoginService( new SimpleLoginService() );
    //...
}

이것은 각 구성 요소를 격리 된 장치로 테스트하는 데 적합합니다. 이제 프로젝트에 수십 개의 클래스가있는 것을 제외하고는 수업을 작성하고 성공적인 단위 테스트를 작성한 후 Spring MVC 컨텍스트 파일을 업데이트하는 것을 잊어 버립니다. 배포 된 응용 프로그램의 실제 배선. 프로젝트를 Tomcat에 배포하고 유선이 아닌 콩에서 많은 NullPointers를 찾을 때 컨텍스트 파일을 업데이트하는 것을 잊었습니다.

그래서 여기 내 질문이 있습니다.

  1. 이것은 나의 첫 번째 스프링 프로젝트입니다. 내가 한 것처럼 개별 콩에 대한 단위 테스트를 작성한 다음 실제 응용 프로그램 컨텍스트에서 예상되는대로 모든 것이 작동하는지 테스트하기 위해 두 번째 테스트 (통합 테스트)를 작성하는 것이 정상입니까? 이를위한 모범 사례가 있습니까?

  2. 또한 단위 테스트를 통합 테스트와 어떻게 분리합니까? 모든 소스 코드가 있습니다 src, 단위가 테스트됩니다 test - 두 번째 테스트 폴더가 있어야합니다 (예 : test-integration) 통합 테스트 사례?

이것이 나의 첫 번째 봄 프로젝트이기 때문에, 나는 다른 사람들이 어떻게 일반적으로 이런 종류의 일을하는지 궁금합니다. 그리고 바퀴를 다시 발명하기보다는 나머지 지역 사회에 묻습니다.

도움이 되었습니까?

해결책

나는 모범 사례에 대해 말할 수 없지만 여기에 내가 과거에 한 일이 있습니다.

단위 테스트 :

  • 사소한 콩에 대한 단위 테스트를 만듭니다 (예 : 대부분의 봄 관련 콩)
  • 실용적인 서비스 (예 : 항상 그렇지는 않지만 대부분) 주사 서비스에 모의를 사용하십시오.
  • 프로젝트에서 이러한 테스트에 대한 표준 명명 규칙을 사용하십시오. test 예배 규칙서. 사용 Test 또는 TestCase 클래스 이름에 대한 접두사 또는 접미사로서 널리 연습되는 것 같습니다.

통합 테스트 :

  • 생성 AbstractIntegrationTestCase a Spring WebApplicationContext Intetgration 테스트 클래제에 사용합니다.
  • 통합 테스트를위한 명명 규칙을 사용하십시오 test 예배 규칙서. 나는 사용했다 IntTest 또는 IntegrationTest 이 테스트의 접두사 또는 접미사로.

세 개 개미를 설정하십시오 test 대상 :

  1. 테스트-모두 (또는 이름을 지정하려는 모든 것) : 실행 장치 및 통합 테스트
  2. 테스트 : 단위 테스트를 실행하십시오 (그만한 것입니다 test 단위 테스트를위한 가장 일반적인 사용법 인 것 같습니다.
  3. 테스트 통합 : 통합 테스트를 실행하십시오.

언급 한 바와 같이, 프로젝트에 적합한 이름 지정 규칙을 사용할 수 있습니다.

통합 테스트에서 단위를 별도의 디렉토리로 분리하는 것에 관해서는 개발자만큼 중요하다고 생각하지 않습니다. 그리고 그들의 도구 쉽게 찾아서 실행할 수 있습니다.

예를 들어, Spring과 함께 작업 한 마지막 Java 프로젝트는 위에서 설명한 내용을 정확하게 사용했으며 통합 테스트 및 단위 테스트가 동일하게 살고 있습니다. test 예배 규칙서. 반면에 프로젝트는 일반 테스트 디렉토리에서 명시 적으로 분리 된 단위와 통합 테스트 디렉토리를 명시 적으로 분리합니다.

다른 팁

몇 가지 고립 된 점 :

예, 스프링 테스트에 대한 일반적인 접근법입니다. 전자가 스프링 컨텍스트를로드하지 않는 단위 테스트 및 통합 테스트.

단위 테스트의 경우 조롱을 고려하여 테스트가 하나의 격리 된 모듈에 중점을 두는지 확인하십시오.

테스트가 많은 종속성으로 배선되는 경우 실제로 단위 테스트가 아닙니다. 이들은 종속성 주입보다는 새로운 의존성을 사용하는 통합 테스트입니다. 생산 응용 프로그램이 봄을 사용할 때 시간 낭비와 복제 노력!

기본 통합 테스트는 스프링 컨텍스트를 제시하는 것이 유용합니다.

@Required 주석은 스프링 배선에서 필요한 종속성을 포착 할 수 있도록 도와 줄 수 있습니다.

어쩌면 Maven을 조사하여 장치를 바인딩하고 통합 테스트를 제공 할 수있는 명백한 단계를 제공합니다. Maven은 봄 커뮤니티에서 상당히 널리 사용됩니다.

순수하게 주석이 달린 정권으로 전환하면 스프링과 함께 많은 지루한 이중 책 보관이 사라집니다. 여기서 @component, @controller, @service 및 @repository와 모든 콩을 주석을 달 수 있습니다. 주사 해야하는 속성에 @autowired를 추가하십시오.

스프링 참조 매뉴얼의 섹션 3.11을 참조하십시오. http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-annotation-config

관련 메모에서, 우리는 Keng이 설명하는 디비전 단위/integratrion 테스트를 사용하고 있습니다. 가장 최근의 정권에서 우리는 또한 세 번째 "클래스"테스트 인 "ComponentTests"를 도입했습니다. 이들은 풀 스프링 배선으로 실행되지만 유선 스텁 구현 (스프링에는 구성 요소 스캔 필터 및 주석 사용)이 있습니다.

우리 가이 일을 한 이유는 일부 "서비스"층의 경우 콩을 수동으로 연결하기 위해 끔찍한 양의 손으로 코딩 된 배선 로직과 때로는 말도 안되는 양의 모의 객체로 끝나기 때문입니다. 5 줄의 테스트를위한 100 줄의 배선은 드문 일이 아닙니다. 구성 요소 테스트는이 문제를 완화시킵니다.

초기화 비 인터페이스 ( "AfterProperTiesset"방법을 구현 함)를 사용하거나 콩에 대한 초과 방법을 지정하십시오. 초기화는 일반적으로 콩에 Init 메소드를 추가하는 것을 기억할 필요가 없기 때문에 일반적으로 더 쉽습니다.

AfterPropertiesset을 사용하여 모든 것이 널이 아닌 것으로 주입되도록하십시오.

웹 응용 프로그램을위한 통합 테스트를 만들었을 때 별도의 디렉토리에 넣었습니다. 그들은 Junit 또는 Testng를 사용하여 구축되었으며 다음과 같은 것을 사용하여 테스트중인 시스템과 상호 작용합니다. 셀렌 마치 웹 페이지가 마치 사용자 인 것처럼 부딪칩니다. 주기는 다음과 같습니다. 컴파일, 단위 테스트 실행, 웹 앱 빌드, 실행중인 서버에 배포하고 테스트를 실행하고 앱을 배포하고 결과를보고합니다. 아이디어는 전체 시스템을 테스트하는 것입니다.

통합 테스트와 별도로 단위 테스트를 실행하는 것과 관련하여 후자를 모두 통합 테스트 디렉토리에 넣고 다음과 같은 접근 방식을 사용하여 IDE/ANT를 사용하여 실행합니다. 이것. 나를 위해 일합니다.

단위 테스트와 통합 테스트의 차이점은 단위 테스트가 컨텍스트를 반드시로드 할 필요는 없으며, 작성한 코드에 초점을 맞추고 있다는 것입니다. 효과가 빠르게 실패합니다. 그러나 통합 테스트의 경우 컨텍스트를로드하고 실제 시나리오와 같은 엔드 투 엔드 테스트를 수행합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top