[특강 내용 정리]테스트코드 - 실습

📚 Mocking이란?

- Mocking은 테스트 코드를 작성할 때, 실제 객체나 외부 의존성을 흉내 내는(Mock) 가짜 객체를 만들어 사용하는 것

- 쉽게 말해, 실제 서비스를 대체할 수 있는 가짜 서비스를 만들고, 그걸 이용해 테스트를 진행하는 기법이다.

---

❓왜 Mocking이 필요한가?

1. 외부 자원에 의존적인 로직 테스트를 간편하게 만들기 위해

Spring 애플리케이션에서 서비스를 테스트하려고 할 때 보통 DB나 외부 API를 호출하는 경우가 많다.

- 만약 실제 DB나 외부 API를 매번 연결해야 한다면, 테스트 환경 세팅이 번거롭고, 네트워크 문제나 DB 셋업 문제 들으로 인해 테스트가 실패하거나, 느려질 수 있다.

- 이런 상황에서 가짜로 DB를 흉내 내는 Mock 객체를 사용하면, DB 연결 없이도 'DB가 있다고 가정'하고 테스트를 진핼 할 수 있다.

 

2. 독립적이고 빠른 테스트

테스트코드는 작은 단위(단위테스트, 유닛테스트)로 빠르게 돌아야 의미가 있다.

- 하지만, 모든 의존 객체를 실제로 연결하면 속도가 느려지고 다른 요소들(네트워크나 DB 상태)에 의존적이 되어 테스트 결과가 일관적이지 않게 된다.

- Mocking을 통해 서비스의 핵심 로직을 독립적으로 검증할 수 있고, 테스트 속도도 매우 빨라져 신뢰도가 높아진다.

 

3. 복잡한 로직을 단순화하고 에러를 일찍 발견 가능

- 테스트할 때 외부 로직을 단순화함으로써, 내 코드가 의도대로 동작하는지 빠르게 확인 할 수 있다.

- 에러가 발생하면 문제를 다른 곳(DB 설정 오류 등)에서 찾기 보다는 해당 메서드의 로직에서 검증이 가능하다.

---

⭐️ Test에서 Mocking이 중요한 이유는?

1. 단위 테스트(유닛 테스트)의 독립성 보장

- 실제 DB, 네트워크, 파일 시스템 등 외부 의존성과 분리함으로써 테스트 실행 속도가 빠르고, 테스트 결과를 안정적으로 재현할 수 있다.

→ 네트워크 상태나 DB 연결에 의존하지 않고도 테스트가 항상 동일한 결과를 내도록 한다.

 

2. 테스트 범위와 정확성 향상

- 원하는 시나리오(성공케이스, 예외케이스)를 구체적으로 설정하고, 해당 시나리오에 대한 응답을 Mock 객체에서 제어할 수 있어 다양한 케이스를 테스트하기 용이하다.

→ 사용자 조회 시 DB가 에러를 반황 이라는 케이스를 실제 DB 세팅 없이도 Mock으로 시뮬레이션이 가능하다.

 

3. 테스트 작성 및 유지보수 용이

- Mock을 사용해 복잡한 의존성을 간단하게 대체하면 테스트코드가 가벼워지고 직관적으로 된다.

- 서비스 로직 변경 시에도, 실제 인프라 설정을 변경할 필요 없이 Mock 응답만 수정하면 되므로 유지보수가 쉽다.

 

4. 빠른 피드백 루프

- TDD나 BDD 시나리오에서 Mock을 사용하면, 애플리케이션 전체를 구동하지 않고도 특정 계층(Controller, Service)만 빠르게 테스트해볼 수 있다.

- 빌드 파이프라인에서도 단위 테스트는 가장 먼저 수행되며, 빠르게 실패 또는 성공 여부를 알려준다.

 

5. 결합도(Coupling) 낮추기

- Mocking은 객체 간 결합을 낮추고, 인터페이스 기반 설계를 독려한다.

- SOLID 원칙 중 DIP(Dependency Inversion Principle)를 지킬 수 있도록 도와준다.

 

6. 비즈니스 로직 검증에 집중

- 외부 시스템/라이브러리 동작까지 고려하지 않고, 순수하게 우리가 작성한 코드의 로직만 검증할 수 있으므로 "무엇이" 문제인지 빠르게 파악할 수 있다.

→ EmailService가 과금 시스템과 어떻게 연동되는지를 전부 통합 테스트하지 전에, EmailService의 핵심 로직만 Mock SMTP 서버로 테스트 해본다.

---

🚨 Mocking 사용시 주의할 점

1. 과도한 Mock 남발

- 모든 의존성을 Mock으로 대체하면, 실제 코드와의 동작 차이를 놓칠 수 있다.

- 분리된 환경에서만 테스트하는 리스크가 있다.

 

2. Mock 객체의 잘못된 설정(Over-stubbing)

- 불필요하게 많은 when() 조건을 설정하면 테스트가 지나치게 세부 구현에 의존적이게 된다.

- 코드 리팩토링 시 Mock 설정 부분이 깨질 확률이 높아진다.

 

3. 테스트 코드 유지보수

- Mock으로 인한 테스트가 복잡해지면, 실제 시스템이 아닌 "Mock 시뮬레이션"만 올바르게 돌고 있는 상황이 생길 수 있다.

- 항상 "실제 로직" 과 "Mock 설정" 간에 갭이 없는지 점검이 필요하다.

 

4. 정확한 Mock 이름짓기

- "MockUserRepository", "StubPatmentService"와 같이 명시적인 네이밍을 쓰면, 테스트코드를 읽는 사람이 바로 인지할 수 있어 유지보수가 쉬워진다.

 

---

📎 Test Double 용어 정리

- Test Double는 스턴트 더블(stunt double)에서 차용한 것

- 테스트중인 시스템의 일부분이 완전히 준비되지 않았거나 테스트하기 어려운 상황에서 그 대안으로 사용될 수 있는 "가짜" 컴포넌트를 의미한다.

- 테스트 더블은 실제 객체의 행동을 모방하며, 테스트가 특정 조건과 상호작용을 쉽게 재현하고 검증할 수 있도록 한다.

 

용어	정의	설명	예시
Dummy	- 아무 역할도 수행하지 않는다. - "자리 채우기" 용도로만 사용	- 메서드 시그니처가 특정 타입의 인자를 필요하지만, 그 인자를 실제로는 전혀 사용하지 않을 때	new DummyUser()객체를 넘기기만 하고, 실제론 해당 객체의 필드나 메서드를 전혀 사용하지 않을 때
Fake	- 실제 구현과 유사 - 프로덕션 품질 수준이 아닌 간이 구현	- 실제 DB 대신 In-Memory DB 사용 - 실제 캐시 대신 메모리 기반 자료구조 사용 - Repository 테스트는 실제 DB는 아니지만, DB처럼 동작하도록 구현한 Fake를 사용하는 것과 유사
Stub	- 호출에 대해 미리 정해진 답변을 반환하도록 설정된 객체 - 특정 상황을 가정해서 결과값을 고정	- 외부 의존성의 복잡한 로직을 테스트에서 분리 - "고정된 응답"을 반환하도록 세팅할 때	- stubRepository.findUser()호출 시 항상 특정 User 객체를 반환하도록 설정
Spy	- Stub의 기능(미리 정해진 답변 반환) + 어떤 메서드가 몇변 호출되었는지 + 어떤 파라미터로 호출되었는지 기록까지 함께해주는 객체	- 실제 로직 흐름을 그대로 따르면서, "호출 이력"을 관찰해야 할 때	- 특정 결과값을 반환하되, 중간에 로깅/호출 횟수 확인 등 부수적 확인이 필요한 경우.
Mock	- 호출 과정(함수 호출 횟수, 파라미터, 순서 등)에 대한 기대치를 미리 설정하고, 실제로 그렇게 호출되었는지 검증할 수 있는 객체	- 외부 의존성을 완전히 대체하고, 행위 기반 검증을 할 때 많이 사용한다.	- Mockito의 when(), verify() 등

 

---

🧭 테스트 코드 실습

# Given , When , Then

# assertThatThrownBy() : 어떤 코드가 실행될 때 에러가 발생하는지 확인 --- .isInstanceOf

# assertThat() : 값이 어떤 조건과 일치하는지 확인(확인 해봐!)

# 테스트코드 클래스 생성 : Command + Shift + T

---

1. Controller 단위 테스트

(1) @WebMvcTest(UserController.class = 클래스명)

- Web과 관련된 컴포넌트(@Controller, @ControllerAdvice 등)만을 로드하여 테스트 환경을 구성

- Service나 Repository 등의 빈은 자동으로 로드되지 않으므로, 테스트에 필요한 다른 레이어의 빈은 Mocking(@MockBean, @MockitoBean 등)하여 주입한다.

 

(2) @MockitoBean

- 3.4.0 버전 이전에는 @MockBean이 쓰였지만 현재는 @MockitoBean이 사용되고 있다.

- given(...).willReturn(...)을 사용할 수 있다.

 

(3) @DisplayName("...")

- 테스트 메서드에 대해 사람이 읽기 좋은 설명을 부여하는 어노테이션이다.

- 테스트 리포트나 IDE의 테스트 패널에 표시되므로 가독성 향상에 도움을 줍니다.

 

(4) @Autowired

- 의존성 주입

@WebMvcTest(UserController.class)
class UserControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @MockitoBean
    UserService userService;

    @Test
    @DisplayName("이메일로 사용자 조회 시 성공적으로 JSON 응답을 반환")
    void getUserByEmail_shouldReturnUser() throws Exception {
        // Given: 준비 - 특정 이메일을 가진 사용자가 존재한다고 가정
        String email = "test@example.com";
        String name = "홍길동";
        User user = new User(1L,name,email);
        given(userService.getUserByEmail(email)).willReturn(user);

        // When: 액션 - 해당 사용자를 조회하는 컨트롤러 호출
        mockMvc.perform(get("/api/users/{email}", email))
                .andExpect(status().isOk())  // Then: 결과 확인 - JSON 결과 확인
                .andExpect(jsonPath("$.name").value(equalTo(name)) )
                .andExpect(jsonPath("$.email").value(equalTo(email)) );
    }
}

                .andExpect(jsonPath("$.name").value(equalTo("name")) )
                .andExpect(jsonPath("$.email").value(equalTo(email)));

→ "jsonPath" : Response에 해당 값이 맞는지 확인하는 작업이므로 Request.jsonPath(동작 안함)가 아닌 "Result.jsonPath"으로 import 필수!

---

2. Service 테스트

(1) @ExtendWith(MockitoExtension.class)

- MockitoExtension은 @Mock, @InjectMocks 등을 해석한다.

- Mock 객체 생성 및 주입을 자동으로 처리한다.

 

(2) @Mock

- Mockito에서 Mock 객체를 생성하기 위한 어노테이션이다.

- when(...), thenReturn(...) 으로 지정(Stubbing)할 수 있다.

 

(3) @InjeckMocks

- Mocking한 모든 애들을 userService와 연결(inject)한다.

 

@ExtendWith(MockitoExtension.class)
class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks		// Mocking한 모든 애들을 userService와 연결(inject)하는 것
    private UserService userService;

    @Test
    @DisplayName("존재하는 이메일로 사용자 조회 시 해당 사용자 반환")
    void getUserByEmail_whenUserExists() {
        String email = "existing@example.com";
        User mockUser = new User(1L,"user",email);

        // Stubbing
        when(userRepository.findByEmail(email)).thenReturn(Optional.of(mockUser));

        // Service 호출
        User foundUser = userService.getUserByEmail(email);

        // 검증
        assertThat(foundUser).isNotNull();
        assertThat(foundUser.getEmail()).isEqualTo(email);
    }

    @Test
    @DisplayName("존재하지 않는 이메일로 사용자 조회 시 예외 발생")
    void getUserByEmail_whenUserNotExists() {
        String email = "notfound@example.com";
        when(userRepository.findByEmail(email)).thenReturn(Optional.empty());

        assertThatThrownBy(() -> userService.getUserByEmail(email))
                .isInstanceOf(IllegalArgumentException.class)
                .hasMessage("User not found");
    }
}

---

3. Repository 테스트

(1) @DataJpaTest

- 기본적으로 인메모리 데이터베이스(H2) 를 사용하도록 설정되어 있다.

- 별도의 DB 설정 없이도 엔티티 매핑과 Repository 동작을 빠르게 테스트할 수 있다.

@DataJpaTest
public class UserRepositoryTest {

    @Autowired
    UserRepository userRepository;

    @Test
    @DisplayName("H2: 이메일로 사용자 검색 시 존재하는 사용자 반환")
    void findByEmail_success() {
        // Given
        User saved = userRepository.save(new User("user","parksw@naver.com"));


        // When
        Optional<User> found = userRepository.findByEmail("parksw@naver.com");

        // Then
        assertThat(found).isPresent();
        assertThat(found.get().getId()).isEqualTo(saved.getId());
        assertThat(found.get().getEmail()).isEqualTo("parksw@naver.com");
    }

    @Test
    @DisplayName("H2: 존재하지 않는 이메일 검색 시 빈 Optional 반환")
    void findByEmail_notFound() {
				// Given test@example.com을 주지 않음
        // When
        Optional<User> found = userRepository.findByEmail("test@example.com");

        // Then
        assertThat(found).isEmpty();
    }
}

 

 

---

4. <혼자 공부> Entity 테스트

(1) @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)

- @DataJpaTest는 기본적은 H2를 적용하는데 나는 database를 mysql로 설정 해두었기 때문에 

 

(2) EntityManager - @PersistenceContext는 짝꿍처럼 같이 다닌다!

- EntityManager이란? 데이터베이스에 데이터를 저장하거나 조회하거나 수정하거나 삭제할 때 사용한다.(데이터베이스와 소통)

- @PersistenceContext란? EntityManager를 스프링이 자동으로 주입해주는 어노테이션이다.(주입 도구)

application.properties

...
spring.jpa.database=mysql

@DataJpaTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
class ItemJPQLTest {

@PersistenceContext
private EntityManager entityManager;

// 생략 ...

}