CHAPTER 7: 대역

테스트 작성하다 보면 외부 요인이 필요한 시점이 있다.

• 테스트 대상에서 파일 시스템을 사용
• 테스트 대상에서 DB로부터 데이터를 조회하거나 데이터를 추가
• 테스트 대상에서 외부의 HTTP 서버와 통신

자동 이체 기능

public class AutoDebitRegisterTest {
    private AutoDebitRegister register;

    @BeforeEach
    void setUp() {
        CardNumberValidator validator = new CardNumberValidator();
        AutoDebitInfoRepository repository = new JpaAutoDebitInfoRepository();
        register = new AutoDebitRegister(validator, repository);
    }

    @Test
    void validCard() {
        // 업체에서 받은 테스트용 유효한 카드 번호 사용
        AutoDebitReq req = new AutoDebitReq("user1", "1234123412341234");
        RegisterResult result = this.register.register(req);
        assertEquals(VALID, result.getValidity());
    }

    @Test
    void theftCard() {
        // 업체에서 받은 도난 테스트용 카드 번호 사용
        AutoDebitReq req = new AutoDebitReq("user1", "1234567890123456");
        RegisterResult result = this.register.register(req);
        assertEquals(THEFT, result.getValidity());
    }
}

문제점

• 카드 번호가 한 달 뒤에 만료되면 테스트 코드를 사용할 수 없음
• 외부 업체가 테스트 용도의 도난 카드 정보를 삭제할 경우

이렇게 테스트 대상에서 의존하는 요인 때문에 테스트가 어려울 때는 대역을 써서 테스트를 진행할 수 있다.

대역을 이용한 테스트

CardNumberValidator 대역 클래스

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;
    }
}

이처럼 단순한 구현으로 실제 구현을 대체한다.

대역을 이용해서 테스트 코드 작성

public class AutoDebitRegister_Stub_Test {
    private AutoDebitRegister register;
    private StubCardNumberValidator stubValidator;
    private StubAutoDebitInfoRepository stubRepository;

    @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());
    }

    @Test
    void theftCard() {
        stubValidator.setTheftNo("1234567890123456");

        AutoDebitReq req = new AutoDebitReq("user1", "1234567890123456");
        RegisterResult result = this.register.register(req);

        assertEquals(CardValidity.THEFT, result.getValidity());
    }

    @Test
    void validCard() {
        AutoDebitReq req = new AutoDebitReq("user1", "1234123412341234");
        RegisterResult result = this.register.register(req);
        assertEquals(VALID, result.getValidity());
    }
}

• AutoDebitRegister 객체는 실제 객체 대신 StubCardNumberValidator을 사용해서 카드번호가 유효한지 검사하고, 도난 카드번호에 대한 자동이체 기능 테스트를 검사한다

DB 연동 코드 대역

대역을 사용하면 DB 없이 AutoDebitRegister를 테스트할 수 있다.

AutoDebitInfoRepository 대역 구현

public class MemoryAutoDebitInfoRepository implements AutoDebitInfoRepository {
    private Map<String, AutoDebitInfo> infos = new HashMap<>();

    @Override
    public void save(AutoDebitInfo info) {
        infos.put(info.getUserId(), info);
    }

    @Override
    public AutoDebitInfo findOne(String userId) {
        return infos.get(userId);
    }
}

MemoryAutoDebitInfoRepository 를 이용한 테스트

public class AutoDebitRegister_Fake_Test {
    private AutoDebitRegister register;
    private StubCardNumberValidator cardNumberValidator;
    private MemoryAutoDebitInfoRepository repository;

    @BeforeEach
    void setUp() {
        cardNumberValidator = new StubCardNumberValidator();
        repository = new MemoryAutoDebitInfoRepository();
        register = new AutoDebitRegister(cardNumberValidator, repository);
    }

    @Test
    void alreadyRegistered_InfoUpdated() {
        repository.save(
                new AutoDebitInfo("user1", "111222333444", LocalDateTime.now()));

        AutoDebitReq req = new AutoDebitReq("user1", "123456789012");
        RegisterResult result = this.register.register(req);

        AutoDebitInfo saved = repository.findOne("user1");
        assertEquals("123456789012", saved.getCardNumber());
    }

    @Test
    void notYetRegistered_newInfoRegistered() {
        AutoDebitReq req = new AutoDebitReq("user1", "1234123412341234");
        RegisterResult result = this.register.register(req);

        AutoDebitInfo saved = repository.findOne("user1");
        assertEquals("1234123412341234", saved.getCardNumber());
    }
}

대역을 사용한 외부 상황 흉내와 결과 검증

• 대역을 이용해서 외부의 상황을 흉내냄
• 대역을 이용하면 외부에 대한 결과를 검증할 수 있음

대역의 종류

대역 종류	설명
Stub	구현을 단순한 것으로 대체한다. 테스트에 맞게 단순히 원하는 동작을 수행한다. 예) StubCardNumberValidator
Fake	제품에는 적합하지 않지만, 실제 동작하는 구현을 제공한다. DB 대신에 메모리를 이용해서 구현한 MemoryAutoDebitInfoRepository가 가짜 대역에 해당한다.
Spy	호출된 내역을 기록한다. 기록한 내용은 테스트 결과를 검증할 때 사용한다. 스텁이기도 하다.
Mock	기대한 대로 상호작용하는지 행위를 검증한다. 기대한 대로 동작하지 않으면 익셉션을 발생할 수 있다. 모의 객체는 스텁이자 스파이도 된다.

대역 종류별 회원가입 기능 테스트

각 타입의 역할

• UserRegister : 회원 가입에 대한 핵심 로직을 수행한다.
• WeakPasswordChecker : 암호가 약한지 검사한다.
• UserRepository : 회원 정보를 저장하고 조회하는 기능을 제공한다.
• EmailNotifier : 이메일 발송 기능을 제공한다.

구현하기 전에 설계

단위 기능을 구현하기에 앞서 어떤 구성 요소가 필요할지 고민하는 것은 의존 대상을 도출할 때 도움이 된다.

Stub: 약한 암호 확인 기능

약한 암호 인지 여부를 알려주기만 하면 되므로 스텁 대역을 사용한다.

Faker: 리포지토리

테스트 골격

• 동일 ID를 가진 회원 존재
• 실행 및 결과 검증

방법

• 리포지토리에 사용자 추가

Spy: 이메일 발송 여부 확인

검증하기 위한 테스트 코드 골격

• 실행: userRegister.register(id, pw, email)
• 결과: email@somedomain.com으로 이메일 발송을 요청했는지 확인

이메일 발송 여부를 어떻게 확인 방법

• UserRegister가 EmailNotifier의 메일 발송 기능을 실행할 때 특정 이메일을 사용했는지 확인

스파이 구현

package com.example.tdd.chap07.user;

public class SpyEmailNotifier implements EmailNotifier {
    private boolean called;
    private String email;

    public boolean isCalled() {
        return called;
    }

    public String getEmail() {
        return email;
    }
}

이 단언을 통과하려면 다음 두가지를 해야한다

• UserRegister가 EmailNotifier의 이메일 발송 기능을 호출
• 스파이의 이메일 발송 기능 구현에서 호출 여부 기록

    // UserRegister
    public void register(String id, String pw, String email) {
        if (passwordChecker.checkPasswordWeak(pw)) {
            throw new WeakPasswordException();
        }
        User user = userRepository.findById(id);
        if (user != null) {
            throw new DupIdException();
        }
        userRepository.save(new User(id, pw, email));

        emailNotifier.sendRegisterEmail(email);
    }

    // SpyEmailNotifier				
    @Override
    public void sendRegisterEmail(String email) {
        this.called = true;
        this.email = email;
    }

Mockito: 모의 객체로 스텁과 스파이 대체

Mockito 기초 사용법

의존 설정

dependencies {
		// mockito 의존 설정
    testImplementation('org.mockito:mockito-core:2.26.0')
}

모의 객체 생성

Mockito.mock() 메서드를 이용하면 특정 타입의 모의 객체를 생성할 수 있다.

Mockito.mock() 메서드는 클래스, 인터페이스, 추상 클래스에 대해 모의 객체를 생성할 수 있다.

    @Test
    void mockStubTest() {
		    // GameNumGen 타입의 모의 객체 생성
        GameNumGen genMock = **mock**(GameNumGen.class);
    }

public interface GameNumGen {
    String generate(GameLevel level);
}

스텁 설정

모의 객체를 생성한 뒤에는 BDDMockito 클래스를 이용해서 모의 객체에 스텁을 구성할 수 있다.

BDDMockito.given

    import static org.mockito.BDDMockito.given;
    
    @Test
    void mockStubTest() {
		    // Mock 생성
        GameNumGen genMock = mock(GameNumGen.class);
        // Stub 구성
        **given(genMock.generate(GameLevel.EASY)).willReturn("123");**
				// Stub 설정에 매칭되는 메서드 실행
        String num = **genMock.generate(GameLevel.EASY)**;
        assertEquals("123", num);
    }
    
    @Test
    void mockThrowTest() {
        GameNumGen genMock = mock(GameNumGen.class);
        **given(genMock.generate(null)).willThrow(new IllegalArgumentException());**

        assertThrows(
                IllegalArgumentException.class,
                () -> **genMock.generate(null)**);
    }

BDDMockito.given을 이용하면 모의 객체의 메서드가 특정 값을 리턴하도록 설정할 수 있다.

• willReturn() 메서드는 스텁을 정의한 메서드가 리턴할 값을 지정한다.
• willThrow() 메서드는 익셉션을 발생하게 설정할 수 있다.

리턴 타입이 void인 메서드에 대해 익셉션을 발생시키는 방법

public class VoidMethodStubTest {
    @Test
    void voidMethodWillThrowTest() {
        List<String> mockList = mock(List.class);
        **willThrow**(UnsupportedOperationException.class)
                .**given**(mockList)
                .clear();

        assertThrows(
                UnsupportedOperationException.class,
                () -> mockList.clear()
        );
    }
}

• given() 메서드는 인자로 전달받은 모의 객체 자신을 리턴하는데 이때 익셉션을 발생할 메서드를 호출한다.
• 익센셥을 발생할 모의 객체 설정

인자 매칭 처리

Mockito는 일치하는 스텁 설정이 없을 경우 리턴 타입의 기본 값을 리턴한다.
예를 들어 리턴 타입이 int면 0을 리턴하고, boolean이면 false를 리턴한다. 기본 데이터 타입이 아닌 String이나 List와 같은 참조 타입이면 null을 리턴한다.

• ArgumentMatchers.any() 메서드는 모든 값에 일치하도록 스텁을 설정한다.
  • any타입(), anyString(), any(), any컬렉션타입(), matches(String || Pattern), eq(값)

스텁을 설정할 메서드의 인자가 두 개 이상인 경우 주의점
Mockito는 한 인자라도 ArgumentMatcher를 사용할 경우 모든 인자를 ArgumentMatcher를 이용해서 설정하도록 하고 있다.

행위 검증

모의 객체의 행위를 검증한다.

모의 객체 genMock의 generate() 메소드가 GameLevel.EASY 인자를 사용해서 호출되었는지 검증한다.

public class GameTest {
    @Test
    void init() {
        GameNumGen genMock = mock(GameNumGen.class);
        Game game = new Game(genMock);
        game.init(GameLevel.EASY);

				**then**(genMock).**should**().generate(GameLevel.EASY);
        // **then**(genMock).**should**(only()).generate(GameLevel.EASY);
    }
}

BDDMockito.then()은 메서드 호출 여부를 검증할 모의 객체를 전달받는다. should() 메서드는 모의 객체의 메서드가 불려야 한다는 것을 설정하고 실제 불려야 할 메서드를 지정한다.

메서드 호출 횟수를 검증할 수 있다.

• only(), times(int), never(), atLeast(int), atLeastOne(), atMost(int)

인자 캡처

단위 테스트를 실행하다보면 모의 객체를 호출할 때 사용한 인자를 검증해야 할 때가 있다.
Mockito의 ArgumentCaptor를 사용하면 메서드 호출 여부를 검증하는 과정에서 실제 호출할 때 전달한 인자를 보관할 수 있다.

    @DisplayName("가입하면 메일을 전송함")
    @Test
    void whenRegisterThenSendMail() {
        userRegister.register("id", "pw", "email@email.com");

        **ArgumentCaptor**<String> captor = **ArgumentCaptor.forClass(String.class);**
        BDDMockito.then(mockEmailNotifier).should()
	        .sendRegisterEmail(**captor.capture()**);

        String realEmail = **captor.getValue()**;
        assertEquals("email@email.com", realEmail);
    }

• `ArgumentCaptor captor = ArgumentCaptor.forClass(String.class);` : String 타입의 인자를 보관할 수있는 ArgumentCaptor를 생성한다.
• BDDMockito.then(mockEmailNotifier).should().sendRegisterEmail(**captor.capture()**); : 모의 객체 호출 여부를 검증하는 코드에서 인자로 전달한다. 인자로 전달할 때는 ArgumentCaptor#captor() 메서드를 전달한다.

JUnit5 확장 설정

mockito-junit-jupiter 의존을 추가하면 애노테이션을 이용해서 모의 객체를 생성할 수 있다.
@Mock 애노테이션을 붙인 필드에 대해 자동으로 모의 객체를 생성해준다.

@ExtendWith(MockitoExtension.class)
public class JUnit5ExtensionTest {
	@Mock
	private GameNumGen genMock;
}

상황과 결과 확인을 위한 협업 대상(의존) 도출과 대역 사용

제어하기 힘든 외부 상황이 존재하면 대역으로 대신할 수 있다

• 제어하기 힘든 외부 상황을 별도 타입으로 분리
• 테스트 코드는 별도로 분리한 타입의 대역을 생성
• 생성한 대역을 테스트 대상의 생성자 등을 이용해서 전달
• 대역을 이용해서 상황 구성

당장 구현하는데 시간이 걸리는 로직도 분리하기에 좋은 후보이다.

대역과 개발 속도

대역을 사용하지 않고 실제 구현을 사용한다면 대기 시간이 발생한다.

• 카드 정보 제공 업체에서 도난 카드번호를 받을 때까지 테스트를 기다린다.
• 카드 정보 제공 API가 비정상 응답을 주는 상황을 테스트하기 위해 업체의 변경 대응을 기다린다.
• 회원 가입 테스트를 한 뒤에 편지가 도착할 때까지 메일함을 확인한다.
• 약한 암호 검사 기능을 개발할 때까지 회원 가입 테스트를 대기한다.

대역을 사용하면 장점

• 실제 구현이 없어도 다양한 상황에 대해 테스트할 수 있다.
• 실제 구현이 없어도 실행 결과를 확인할 수 있다.

모의 객체를 과하기 사용하지 않기

문제

save() 메서드가 호출되었는지 확인해야 하고 ArgumentCaptor를 이용해서 호출할 때 전달한 인자를 저장해야 한다. → 테스트 코드가 복잡해짐

해결

메모리를 이용한 가짜 구현을 사용하면 코드가 단순해지고 의미도 명확하다.

모의 객체를 이용하면 대역 클래스를 만들지 않아도 되니까 편할 수 있다.

하지만 결과 값을 확인하는 수단으로 모의 객체를 사용하기 시작하면 결과 검증 코드가 길어지고 복잡해진다.

---

Chapter 08: 테스트 가능한 설계

테스트가 어려운 코드	테스트 가능한 설계	추가 설명
하드 코딩된 경로	경로나 상수를 생성자나 메서드 파라미터로 받기	하드 코딩된 값을 제거하고, 유연하게 변경할 수 있도록 설정하거나 주입함으로써 다양한 테스트 시나리오를 적용할 수 있음.
하드 코딩된 상수	상수를 생성자나 메서드 파라미터로 받기	상수를 외부에서 주입받음으로써 다양한 환경에서의 동작을 테스트할 수 있으며, 코드의 재사용성도 높아짐.
의존 객체를 직접 생성	의존 대상을 주입받기 (생성자 또는 세터를 통해)	직접 객체를 생성하면 테스트 중에 모킹이 어려움. 주입받도록 설계하면 의존성을 쉽게 교체하거나 모킹할 수 있어 테스트가 용이해짐.
정적 메서드 사용	인스턴스 메서드로 변경하거나, 테스트 가능한 구조로 변경	정적 메서드는 상태를 가지지 않기 때문에 테스트가 어려울 수 있음. 이를 인스턴스 메서드로 변경하거나, 정적 메서드를 감싸는 클래스를 사용하여 유연성을 높임.
외부 라이브러리를 직접 사용	외부 라이브러리를 감싸는 래퍼 클래스를 만들어 사용	외부 라이브러리에 대한 직접적인 의존성을 줄이고, 변경 시에도 래퍼 클래스만 수정하면 되므로 유지보수성이 향상되며, 모킹을 통해 테스트도 쉬워짐.
실행 시점에 따라 달라지는 결과	테스트하고 싶은 코드 분리, 예측 가능한 입력과 출력으로 변경	실행 시점에 따라 달라지는 부분을 분리하여 예측 가능한 결과를 제공하도록 설계하면 테스트의 일관성을 유지할 수 있음. 특히, 시간이나 랜덤 값을 분리하는 것이 중요.
역할이 섞여 있는 코드	각 역할을 담당하는 클래스로 분리하기	단일 책임 원칙(SRP)을 적용하여 코드를 분리하면 각 역할에 대한 테스트가 명확해지고, 코드의 가독성과 유지보수성이 향상됨.
시간이나 임의 값 생성 기능 포함	시간이나 임의 값 생성을 인터페이스로 추상화하여 주입 받기	시간이나 랜덤 값 생성 로직을 인터페이스로 분리하고 주입받으면, 테스트 시 원하는 값을 쉽게 모킹할 수 있어 예측 가능한 테스트가 가능해짐.
복잡한 비즈니스 로직이 포함된 메서드	복잡한 로직을 작은 단위로 분리하고, 각각을 개별적으로 테스트하기	복잡한 로직은 작은 메서드로 분리하여 각각의 메서드를 개별적으로 테스트할 수 있도록 설계. 이는 디버깅과 코드 이해도를 높이고, 테스트를 보다 철저하게 수행할 수 있게 함.
비동기 코드, 콜백 사용	비동기 코드를 동기 코드로 감싸거나, 비동기 호출을 추상화하여 테스트하기	비동기 코드의 테스트는 어려울 수 있으므로, 동기적으로 동작하게 하거나 추상화된 인터페이스로 감싸서 테스트할 수 있도록 설계.
파일, 네트워크, DB와 같은 외부 리소스에 의존하는 코드	외부 리소스 접근을 인터페이스로 추상화하고, 테스트 시 모의 객체(mock)를 사용	외부 리소스에 의존하는 코드를 추상화하여 의존성을 줄이고, 테스트 중에는 모의 객체를 사용함으로써 테스트가 독립적으로 이루어질 수 있게 함.
그 외 테스트하기 어려운 코드	단일 책임 원칙(SRP)을 적용하여 코드 분리, 테스트 가능한 코드로 리팩토링	단일 책임 원칙을 적용하면 코드를 명확하게 분리할 수 있어, 각 부분을 독립적으로 테스트하고 유지보수하는 것이 용이해짐.