목차
대역 필요성
"자동이체 기능"을 테스트하기 위한 외부 서비스에서 제공되는 정보를 이용하여 구현 시 문제가 되는 상황들
- 해당 업체에서 상황별로 테스트 할 수 있는 카드번호 받아야함
- 외부서비스에서 실수로 유효한 카드번호 삭제
- 발급 받은 유요한 카드번호의 유효기간 지남
외부 서비스에서 제공하는 HTTP URL을 이용하여 제공되는 정보 구현이 어려움
외부요인이 테스트에 관여하는 주요 예시
- 테스트 대상에서 파일 시스템을 이용
- 테스트 대상에서 DB로 부터 데이터를 조회하거나 데이터를 추가
- 테스트 대상에서 외부 HTTP 서버와 통신
TDD 는 "테스트 작성 -> 통과시킬 만큼 구형 -> 리팩토링" 의 과정을 짧은 흐름으로 반복해야 한다.
하지만, 테스트 대상이 이런 외부 요인에 의존하면 테스트를 작성하고 실행하기 어려워지며 실행 결과를 예측할 수 없게 만든다.
→ 이럴 때 외부 요인을 대신하는 대역을 이용하여 테스트를 작성한다.
대역을 이용한 테스트
대역을 이용하여 "자동이체 기능" 을 테스트하는 코드 작성해보기
CardNumberValidation을 대신한 대역 클래스
public class StubCardNumberValidator extends CardNumberValidator {
private String invalidNo;
private String theftNo;
public void setInvalidNo(String invalidNo) {
this.invalidNo = invalidNo;
}
public void setTheftNo(String theftNo) {
this.theftNo = theftNo;
}
@Override
public CardValidity validate(String cardNumber) {
if (invalidNo != null && invalidNo.equals(cardNumber)) {
return CardValidity.INVALID;
}
if (theftNo != null && theftNo.equals(cardNumber)) {
return CardValidity.THEFT;
}
return CardValidity.VALID;
}
}
- StubCardNumberValidation 에서 실제 카드번호 검증 기능을 구현하지 않고, VALID, INVALID 를 리턴하는 단순한 구현으로 대체
테스트 코드에 적용
....
@BeforeEach
void setUp() {
stubValidator = new StubCardNumberValidator();
stubRepository = new StubAutoDebitInfoRepository();
register = new AutoDebitRegister(stubValidator, stubRepository);
}
@Test
void invalidCard() {
stubValidator.setInvalidNo("111122223333");
AutoDebitReq req = new AutoDebitReq("user1", "111122223333");
RegisterResult result = this.register.register(req);
assertEquals(INVALID, result.getValidity());
}
이와 같이 대역을 이용하면 필요한 외부 서비스 api 를 흉내내서 테스트에 적용할 수도 있다.
또한, DB 없이 DB 역할을 하는 클래스를 간단한게 구현하여 적용할 수도 있다.
대역의 종류
| 대역 종류 |
설명 |
| 스텁(Stub) |
구현을 단순한 것으로 대체한다. 테스트를 위해 필요한 값만 제공하면 된다. |
| 가짜(Fake) |
제품에는 적합하지 않지만, 실제 동작하는 구현을 제공한다. DB 대신에 메모리를 이용해서 구현하는 방식이 이에 해당한다. |
| 스파이(Spy) |
호출된 내역을 기록한다. 기록한 내용은 테스트 결과를 검증할 때 사용한다. |
| 모의(Mock) |
기대한 대로 상호작용하는지 검증한다. 기대한 대로 동작하지 않으면 익셉션을 발생할 수 있다. 모듸 객체는 스텁이자 스파이도 된다. |
❏ 약한 암호 확인 기능에 스텁 사용 ➡︎ 테스트를 위해 필요한 값 (암호가 약하다고 응답)만 제공
- 실제 동작을 구현할 필요 x → 단순하게 약한 암호인지만 알려주면 된다.(스텁)
- 스텁으로 하여금 암호 확인 요청이 오면 암호가 약하다고 응답하라고 설정
- 실제 테스트 하는 클래스에 스텁용 클래스를 주입하여 결과를 리턴
❏ 리포지토리를 가짜 구현으로 사용 ➡︎ 리포지토리의 기본 기능을 구현
- 동일한 ID를 가진 회원이 존재할 경우 익셉셥을 발생하는 테스트 → 가짜로 회원을 추가
- User 클래스를 생성 - 엔티티 구현
- 가짜 DB 로 MemoryUserRepository 클래스 구현
- UserRepository 를 구현해서 가짜 DB에 메서드 추가
Note : 상수를 이용하여 테스트를 통과시킨 다음에 구현을 일반화할 방법이 떠오르지 않으면
예를 추가하면서 점진적으로 구현을 완성해 나가면 된다.
❏ 이메일 발송 여부를 확인하기 위해 스파이를 사용
회원 가입에 성공하면 회원 가입 안내 메일 발송 여부를 확인하는 방법
- 회원 가입 후 EmailNotifier "메일 발송 기능" 을 실행할 때 "가입한 이메일 주소" 를 사용했는지 확인
EmailNotifier 의 스파이 대역(class SpyEmailNotifier) 구현하여 이메일 발송여부를 확인
- 이메일 발송 기능을 호출 → SpyEmailNotifier 에서 호출 됨를 저장하여 True 로 반환
- 이메일 발송 기능을 호출 → SpyEmailNotifier 에서 가입시 사용된 이메일을 저장하여 해당 이메일을 반환
assertTrue(spyEmailNotifier.isCalled());
assertEquals("email@email.com", spyEmailNotifier.getEmail());
❏ 모의 객체로 스텁과 스파이 대체
- 주요기능 : 대역 객체(스텁, 스파이) 가 기대하는대로 상호작용했는지 확인하는 것
모의 객체를 위한 도구를 이용하면, 모의 객체가 기대하는대로 상호작용했는지 검증이 가능하다.
상황과 결과 확인을 위한 협업 대상(의존) 도출과 대역 사용
외부 API 를 직접 연동하여 테스트 코드에서 상황을 구현하거나 결과를 확인하기 어렵다.
이렇게 제어하기 힘든 외부상황이 존재하면 아래의 방법으로 의존을 도출하고 이를 대역으로 대신 할 수 있다.
- 제어하기 힘든 외부 상황을 별도 타입으로 분리
- 테스트 코드는 별도로 분리한 타입의 대역을 생성
- 생성한 대역을 테스트 대상의 생성자 등을 이용해서 전달
- 대역을 이용해서 상황 구성
"자동 이체 정보 등록 기능" 에서 외부 상황 분리
- 카드번호가 유효한지 검사 하는 기능을 별도 타입으로 분리하고 대역을 생성
- 별도 타입 : 카드번호 검사 기능 → 대역을 이용하여 구현 및 생성
회원 가입에 성공한 경우 이메일을 발송하는 기능
- 회원 가입 기능 실행 이후에 이메일 발송 여부를 확인할 수단 필요
- 이메일 발송 자체를 UserResiter 에서 구현하면 발송 여부를 확인하기 어려움
- 결과 확인과 관련된 기능을 별도 타입으로 분리 → 대역으로 대체
당장 구현하기 어렵거나 오래걸리는 로직도 분리하기에 좋은 후보다.
대역과 개발 속도
TDD 과정에서 대역을 사용하지 않고 실제 구현을 사용한다면 발생하는 상황들
- 카드 정보 제공 업체에서 도난 카드번호를 받을 때까지 테스트를 기다린다.
- 카드 정보 제공 API가 비정상 응답을 주는 상황을 테스트하기 위해 업체의 변경 대응을 기다린다.
- 회원 가입 테스트를 한 뒤에 편지가 도착할 때까지 메일함을 확인한다.
- 약한 암호 검사 기능을 개발할 때까지 회원 가입 테스트를 대기한다.
모두 대기 시간이 발생 ➔ 대역을 사용하면 실제 구현이 없어도 실행 결과를 확인 가능
대역은 의존하는 대상을 구현하지 않아도 테스트 대상을 완성할 수 있게 만들어주며
이는 대기시간을 줄여주어 개발 속도를 올리는데 도움이 된다.
모의 객체를 과하게 사용하지 않기
모의 객체 사용의 편리성
- 대역 클래스를 직접 만들 필요 없이 테스트 가능.
문제점
- 결과 검증 코드가 길고 복잡해짐.
- 여러 모의 객체 사용 시 코드 복잡도 증가.
- 메서드 호출 검증 위주로 상호 작용이 조금만 바뀌어도 테스트가 깨질 위험.
주의사항
- 모의 객체의 메서드 호출을 결과 검증의 주 수단으로 사용하지 말 것.
대안
- DAO나 리포지토리 등 저장소에 대한 대역으로 메모리 기반의 가짜 구현 사용 권장.
- 테스트 코드 관리가 용이해짐.
실용적 접근법
- 모의 객체는 필요한 곳에 최소한으로 사용
- 단위 테스트에서 모의 객체를 과도하게 사용하는 것보다, 통합 테스트를 통해 실제 상호작용을 검증하는 것이 좋음
