Loading...
Spring Framework Reference Documentation 7.0.2의 Integration Testing의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
애플리케이션 서버에 배포를 하거나 다른 엔터프라이즈 인프라스트럭처에 연결할 필요 없이 일부 통합 테스트를 수행할 수 있는 것이 중요합니다. 이렇게 하면 다음과 같은 것들을 테스트할 수 있습니다:
Spring Framework는 spring-test 모듈에서 통합 테스트에 대한 일급 지원을 제공합니다. 실제 JAR 파일의 이름에는 얻는 위치에 따라 릴리스 버전이 포함될 수 있습니다 (자세한 내용은 Spring Framework Artifacts wiki 페이지를 참조하십시오). 이 라이브러리에는 Spring 컨테이너와 함께 통합 테스트를 위한 유용한 클래스를 포함하는 org.springframework.test 패키지가 포함되어 있습니다.
이 테스트는 애플리케이션 서버나 다른 배포 환경에 의존하지 않습니다. 이러한 테스트는 단위 테스트보다 실행 속도가 느리지만, 애플리케이션 서버에 배포에 의존하는 동등한 Selenium 테스트나 원격 테스트보다 훨씬 빠릅니다.
단위 및 통합 테스트 지원은 어노테이션 기반 Spring TestContext Framework의 형태로 제공됩니다. TestContext 프레임워크는 실제로 사용 중인 테스트 프레임워크에 대해 agnostic하므로 JUnit, TestNG 등을 포함한 다양한 환경에서 테스트의 instrumentation을 허용합니다.
다음 섹션에서는 Spring의 통합 지원의 상위 수준 목표에 대한 개요를 제공하고, 이 장의 나머지 부분은 다음의 개별 토픽에 중점을 둡니다:
Spring의 통합 테스트 지원은 다음과 같은 primary goal을 갖습니다:
다음 몇 개의 섹션에서는 각 goal을 설명하고 구현 및 설정 detail에 대한 링크를 제공합니다.
Spring TestContext Framework는 Spring ApplicationContext 인스턴스와 WebApplicationContext 인스턴스의 일관된 로딩과 이러한 컨텍스트의 캐싱을 제공합니다. 로드된 컨텍스트의 캐싱 지원은 중요합니다. 왜냐하면 시작 시간이 issue가 될 수 있기 때문입니다.
이는 Spring 자체의 오버헤드 때문이 아니라, Spring 컨테이너에 의해 생성되는 객체가 생성되는 데 시간이 걸리기 때문입니다. 예를 들어, 50에서 100개의 Hibernate 매핑 파일이 있는 프로젝트는 매핑 파일을 로드하는 데 10에서 20초가 걸릴 수 있으며, 모든 테스트 픽스처에서 모든 테스트를 실행하기 전에 그 비용을 부담하면 전체 테스트 실행 속도가 느려져 개발자 생산성이 떨어집니다.
테스트 클래스는 일반적으로 classpath에 있는 XML 또는 Groovy 설정 메타데이터에 대한 리소스 위치 배열이나 애플리케이션을 구성하는 데 사용되는 컴포넌트 클래스 배열을 선언합니다. 이러한 위치나 클래스는 프로덕션 배포를 위한 web.xml 또는 다른 설정 파일에 지정된 것과 같거나 유사합니다.
기본적으로 한 번 로드되면, 구성된 ApplicationContext는 각 테스트에 대해 재사용됩니다. 따라서 setup 비용은 테스트 스위트당 한 번만 발생하며 이후 테스트 실행은 훨씬 빠릅니다. 이 컨텍스트에서 “테스트 스위트”라는 용어는 동일한 JVM에서 실행되는 모든 테스트를 의미합니다.
예를 들어, 특정 프로젝트나 모듈에 대해 Ant, Maven 또는 Gradle 빌드에서 실행되는 모든 테스트입니다. 어떤 테스트가 애플리케이션 컨텍스트를 손상시키고 재로딩이 필요한 경우(예를 들어, 빈 정의나 애플리케이션 객체의 상태를 수정하는 경우), TestContext 프레임워크를 구성하여 다음 테스트를 실행하기 전에 설정을 다시 로드하고 애플리케이션 컨텍스트를 재구축할 수 있습니다.
TestContext 프레임워크와 함께 Context Management 및 Context Caching을 참조하십시오.
TestContext 프레임워크가 애플리케이션 컨텍스트를 로드할 때 의존성 주입을 사용하여 테스트 클래스 인스턴스를 선택적으로 구성할 수 있습니다. 이는 애플리케이션 컨텍스트에서 미리 구성된 빈을 사용하여 테스트 픽스처를 설정하는 편리한 메커니즘을 제공합니다.
여기서의 큰 이점은 애플리케이션 컨텍스트를 다양한 테스트 시나리오(예: Spring-managed 객체 그래프, 트랜잭션 프록시, DataSource 인스턴스 등의 구성)에 걸쳐 재사용할 수 있으므로 개별 테스트 케이스에 대한 복잡한 테스트 픽스처 setup을 중복할 필요가 없다는 점입니다.
예로, Title 도메인 엔티티에 대한 데이터 액세스 로직을 구현하는 클래스 (HibernateTitleRepository)가 있는 시나리오를 생각해 보겠습니다. 우리는 다음 영역을 테스트하는 통합 테스트를 작성하고자 합니다:
HibernateTitleRepository 빈의 설정과 관련된 모든 것이 올바르고 존재하는가?HibernateTitleRepository의 로직: 이 클래스의 구성된 인스턴스가 예상대로 동작하는가?TestContext framework를 사용한 테스트 픽스처의 의존성 주입을 참조하십시오.
실제 데이터베이스에 액세스하는 테스트에서 흔한 issue 중 하나는 퍼시스턴스 저장소 상태에 미치는 영향입니다. 개발 데이터베이스를 사용하더라도 상태에 대한 변경은 향후 테스트에 영향을 줄 수 있습니다. 또한, 퍼시스턴트 데이터를 insert하거나 수정하는 것과 같은 많은 operation은 트랜잭션 밖에서 수행(또는 검증)할 수 없습니다.
TestContext 프레임워크는 이 issue를 해결합니다. 기본적으로 프레임워크는 각 테스트에 대해 트랜잭션을 생성하고 롤백합니다. 트랜잭션의 존재를 가정하는 코드를 작성할 수 있습니다.
테스트에서 트랜잭션 프록시된 객체를 호출하면, 해당 객체는 구성된 트랜잭션 의미에 따라 올바르게 동작합니다. 또한, 테스트 메서드가 테스트를 위해 관리되는 트랜잭션 내에서 실행되는 동안 선택된 테이블의 내용을 삭제하는 경우, 트랜잭션은 기본적으로 롤백되며 데이터베이스는 테스트 실행 이전의 상태로 돌아갑니다. 트랜잭션 지원은 테스트의 애플리케이션 컨텍스트에 정의된 PlatformTransactionManager 빈을 사용하여 테스트에 제공됩니다.
트랜잭션이 커밋되도록 하려면(특정 테스트가 데이터베이스를 채우거나 수정하도록 하려는 경우처럼 드물지만 가끔 유용함), TestContext 프레임워크에 @Commit 어노테이션을 사용하여 트랜잭션이 롤백 대신 커밋되도록 지시할 수 있습니다.
TestContext framework를 사용한 트랜잭션 관리를 참조하십시오.
Spring TestContext Framework는 통합 테스트 작성을 단순화하는 여러 abstract 지원 클래스를 제공합니다. 이러한 기본 테스트 클래스는 테스트 프레임워크에 대한 잘 정의된 hook과 편리한 인스턴스 변수 및 메서드를 제공하여 다음에 액세스할 수 있게 합니다:
ApplicationContext.JdbcTemplate. 이러한 쿼리를 사용하여 데이터베이스 관련 애플리케이션 코드 실행 전후의 데이터베이스 상태를 확인할 수 있으며, Spring은 이러한 쿼리가 애플리케이션 코드와 동일한 트랜잭션 스코프 내에서 실행되도록 보장합니다. ORM 도구와 함께 사용할 때는 false positive를 피하도록 주의해야 합니다.또한, 프로젝트에 특화된 인스턴스 변수 및 메서드를 가진 custom한 애플리케이션 전체 슈퍼클래스를 직접 만들고 싶을 수도 있습니다.
TestContext framework를 위한 지원 클래스를 참조하십시오.
Unit Testing
JDBC Testing Support