토비의 스프링 3.1 - 2장

토비의 스프링 chap 2 - 테스트

단위 테스트 (Unit Test)

작은 단위의 코드에 대해 테스트를 수행하는 것.
일반적으로 단위는 작을수록 좋다.
단위 테스트를 하는 이유는 개발자가 설계하고 만든 코드가 원래 의도한 대로 동작하는지를 개발자 스스로 빠르게 확인받기 위해서다.

통합 테스트 (Integration Test)

통합 테스트는 단위 테스트보다 더 큰 동작을 달성하기 위해 여러 모듈들을 모아 이들이 의도대로 협력하는지 확인하는 테스트다.
각 단위들이 유기적으로 잘 동작하는지를 검증한다.
통합 테스트는 단위 테스트와 다르게 개발자가 변경할 수 없는 부분(ex 외부 라이브러리) 까지 묶어 검증할 때 사용한다.
@SpringBootTest 어노테이션을 붙여 통합 테스트를 수행할 수 있다.

장점

• 단위 테스트에서 발견하기 어려운 버그를 찾을 수 있다.

단점

• 단위 테스트보다 더 많은 코드를 테스트하므로 신뢰성이 떨어질 수 있다.
• 어디서 에러가 발생했는지 파악이 쉽지않다.

인수 테스트 (Acceptance Test)

인수 테스트는 사용자 스토리에 맞춰 수행하는 테스트이다.
요구사항을 만족하는지를 검증한다.
예를들어 유저가 회원가입 하고 로그인 하는 과정등을 인수 테스트로 테스트할 수 있다.

예시로 알아보는 테스트

게임을 예시로 들어보자.
유저는 다음의 기능을 이용할 수 있다.

• 공격 (attack)
• 방어 (defense)
• 이동 (move)

여기서 단위 테스트는 attack, defense, move 각각의 메서드에 대한 테스트를 진행하는 것이다.
통합 테스트는 유저가 몬스터를 처치하고 얻는 경험치가 데이터베이스에 잘 들어갔는지 등의 테스트를 진행하는 것이다.
인수 테스트는 유저가 지도를 펼치는 동작을 진행 시 아래의 인수 조건을 테스트한다.

시나리오: 지도 조회
Given: 지도 생성을 요청하고
When: 생성한 지도 조회를 요청 하면
Then: 생성한 지도 정보를 응답받는다

픽스처

테스트를 수행하는데 필요한 정보나 오브젝트를 픽스처(fixture)라고 한다.
동일한 인스턴스를 매번 만들기보다는 픽스처로 구성하여 관리하면 테스트하기 편리하다.

테스트 클래스의 컨텍스트 공유

스프링은 테스트 클래스 사이에서 애플리케이션 컨텍스트를 공유하기 해준다.
즉, 2개의 테스트 클래스가 같은 설정파일을 사용하면 설정파일을 각각 만드는게 아니라 1개만 만들어서 공유하게 된다.
이 덕분에 테스트 성능이 대폭 향상되는 장점이 있다.

DI 주입 대상 변수 타입

DI 로 주입하는 변수의 타입을 인터페이스로 보통 지정하게 되는데, 실제 인스턴스 타입으로 지정하지 않는 이유는?

1. 소프트웨어 개발에서 절대로 바뀌지 않는 것은 없다.
2. 클래스의 구현 방식은 바뀌지 않는다고 하더라도 인터페이스를 두고 DI 를 적용하게 하면 다른 차원의 서비스 기능을 도입할 수 있다.
3. 테스트 코드에서 DI 하기가 수월해진다.

DI 를 이용한 테스트 방법 선택

어떤 방식으로 DI를 테스트에 이용하는게 효율적일까?

항상 스프링 컨테이너 없이 테스트할 수 있는 방법을 가장 우선적으로 고려하라.

테스트 수행 속도가 가장 빠르고 테스트가 간결하다.

여러 오브젝트와 복잡한 의존관계를 갖고 있는 오브젝트 테스트

스프링 설정을 이용한 DI 방식의 테스트를 이용하라.

예외적인 의존관계를 강제로 구성해 테스트하는 경우

테스트 메서드나 클래스에 @DirtiesContext 애노테이션을 사용하자.

참고

• 단위 테스트 vs 통합 테스트 vs 인수 테스트
• Test 유닛 테스트(Unit Test), 통합 테스트(Integration Test), 기능 테스트(Functional Test)란? — 코덕 개발자 노트
• ATDD 1. ATDD(Acceptance Test Driven Development)
• 토비의 스프링 3.1 Vol.1