통합테스트의 역할, 적용 시점, 다른 기법과의 의존

통합테스트란?

단위테스트의 3가지 요구사항

• 단일 동작단위 검증
• 빠르게 수행
• 다른 테스트와 별도로 처리

→ 이 세가지 중에 하나도 충족을 못할 시 통합테스트(단위테스트가 아닌 모든테스트가 통합테스트)

단위테스트와 통합테스트

• 단위테스트와 통합테스트간에 균형을 유지하는 것이 중요
• 단위테스트로 가능한 한 많이 비즈니스 시나리오의 예외 상황을 확인하고 통합테스트는 주요 흐름과 단위테스트가 다루지 못하는 기타 예외사항을 다뤄야한다.(모든 프로세스의 외부의존성을 거치는 것)

빠른 실패원칙 : 예기치 않은 오류가 발생하자마자 현재 연산을 중단

프로세스 외부 의존성의 2가지 유형

• 관리의존성 : 애플리케이션을 통해서만 접근가능 ex) 데이터베이스 등
• 비관리 의존성 : 외부에서 상호작용을 볼 수 있음 ex) SMTP, 메세지버스 등

→ 통합테스트에서는 관리의존성은 실제 인스턴스를 사용하고 비관리 의존성은 목으로 대체하라

데이터베이스를 그대로 테스트할 수 없으면 통합테스트를 아예 작성하지말고 도메인 모델의 단위테스트에만 집중해야한다.

앤드 투 앤드 테스트

통합테스트와는 다르게 어떤 프로세스 외부 의존성도 목으로 대체하지 않는 테스트

데이터베이스나 메세지 버스와 같은 프로세스 외부 의존성을 위해 인터페이스를 도입할때의 오해(아래코드를 지양)

public interface IUserRepository
public class UserRepository: IUserRepository

• 단일 구현을 위한 인터페이스는 추상화가 아니며, 해당 인터페이스를 구현하는 구체 클래스보다 결합도가 낮지 않음
• 코드를 작성하는 것은 문제를 해결하는 값비싼 방법이다. 해결책에 필요한 코드가 적고 간단할 수록 좋음

프로세스 외부 의존성에 인터페이스를 사용하는 이유는 간단히 목을 사용하기위함

→ 의존성을 목으로 처리할 필요가 없는 한, 프로세스 외부 의존성에 대해서만 인터페이스를 사용하자.

통합테스트를 활용하는 데 도움이 되는 지침

• 도메인 모델 경계 명시
• 애플리케이션 내 계층 줄이기
• 순환 의존성 제거 ex) CallBack제거
• 테스트에서 다중 실행 구절사용을 지양하자

결론

식별할수있는 동작인지 구현세부사항인지 여부에 대한 관점으로 프로세스 외부 의존성과의 통신을 살펴봐야함.

ex) 개발자가 아닌사람이 로그를 볼수 있다면 목으로 처리, 아니면 테스트x

 

혼자 단위테스트라는 책을 읽으면서 생각에 흐름대로 적은 글입니다..
참고한 책은 단위 테스트라는 책입니다. ( http://www.yes24.com/Product/Goods/104084175 )