단위/통합 테스트

테스트는 "얼마나 넓은 범위를 한 번에 검증하느냐"에 따라 나뉜다. 작은 부품 하나만 빠르게 보는 단위 테스트, 여러 부품을 실제로 엮어서 보는 통합 테스트다. 둘은 경쟁 관계가 아니라 역할이 다르며, 좋은 프로젝트는 둘을 함께 쓴다.

#1. 단위 테스트 vs 통합 테스트

#2. 가짜(Fake)와 목(Mock)

단위 테스트는 컨테이너를 띄우지 않으므로, 대상이 의존하는 객체(예: DB를 쓰는 Repository)를 진짜 대신 가짜로 넣어 준다. 그래야 DB 없이도, 빠르게, 원하는 상황을 만들어 검증할 수 있다.

• Fake(가짜) — 동작은 하지만 단순화된 직접 만든 구현체. 예: DB 대신 Map에 저장하는 Repository.

• Mock(목) — 라이브러리(Mockito)가 만들어 주는 흉내 객체. "이 메소드를 부르면 이 값을 주라"고 지정한다.

// Fake : DB 대신 메모리에 저장하는 가짜 구현
class FakeMemberRepository implements MemberRepository {
    private final Map<Long, Member> store = new HashMap<>();
    public Member save(Member m) { store.put(m.getId(), m); return m; }
    public Member findById(Long id) { return store.get(id); }
}

#3. 순수 단위 테스트 — 생성자 주입이 빛나는 지점

Spring MVC — 의존성 주입에서 본 문제를 다시 보자. 필드 주입은 의존성을 넣을 통로(생성자·setter)가 없어, 스프링 없이 테스트하면 의존성이 null로 남아 막힌다.

반면 생성자 주입이면 가짜를 그냥 생성자로 넘기면 끝이다. 컨테이너가 필요 없다.

class MemberServiceTest {

    @Test
    void 회원을_저장한다() {
        // given : 가짜 Repository를 생성자로 주입 (스프링 컨테이너 X)
        MemberService service = new MemberService(new FakeMemberRepository());

        // when
        Member saved = service.join(new Member(1L, "kim"));

        // then
        assertThat(saved.getName()).isEqualTo("kim");
    }
}

#Mockito로 목 객체 쓰기

앞에서는 FakeMemberRepository를 직접 만들었다. 인터페이스의 모든 메소드를 구현해야 해서 번거롭다. Mockito는 이 가짜 객체를 자동으로 만들어 주는 라이브러리다. spring-boot-starter-test에 기본 포함되어 있어 따로 추가할 필요가 없다.

Mockito의 핵심은 두 가지다.

• 스터빙(stubbing) — "이 메소드를 이렇게 부르면 이 값을 돌려줘"라고 응답을 미리 지정하는 것. when(...).thenReturn(...) 으로 쓴다.

• 검증(verify) — 테스트 대상이 그 목의 메소드를 실제로 호출했는지 확인하는 것. verify(...) 로 쓴다.

import static org.mockito.Mockito.*;

@Test
void 아이디로_조회() {
    // ① 목 생성 : 구현 없이 껍데기만 있는 가짜 객체
    MemberRepository repo = mock(MemberRepository.class);

    // ② 스터빙 : "findById(1L)을 부르면 이 회원을 돌려줘"라고 응답을 미리 정의
    when(repo.findById(1L)).thenReturn(Optional.of(new Member(1L, "kim")));

    MemberService service = new MemberService(repo);   // 생성자 주입

    // ③ 실행 & 검증
    assertThat(service.find(1L).getName()).isEqualTo("kim");

    // ④ 호출 검증 : service가 repo.findById(1L)을 정확히 1번 불렀는가
    verify(repo, times(1)).findById(1L);
}

#어노테이션으로 더 간결하게

mock(...)을 직접 부르는 대신, 어노테이션으로 목 생성과 주입을 자동화할 수 있다.

@ExtendWith(MockitoExtension.class)   // JUnit5에 Mockito 연동
class MemberServiceTest {

    @Mock                              // 목 객체 자동 생성
    MemberRepository repo;

    @InjectMocks                       // 위 목들을 생성자로 주입한 대상 생성
    MemberService service;

    @Test
    void 아이디로_조회() {
        when(repo.findById(1L)).thenReturn(Optional.of(new Member(1L, "kim")));
        assertThat(service.find(1L).getName()).isEqualTo("kim");
    }
}

#4. 통합 테스트 — @SpringBootTest

실제로 컨테이너를 띄워 여러 빈을 엮어 검증하고 싶을 때는 @SpringBootTest를 쓴다. 스프링이 빈을 만들고 주입해 주므로, 테스트에는 @Autowired로 받아서 쓴다.

@SpringBootTest          // 스프링 컨테이너를 띄운다
class MemberServiceIntegrationTest {

    @Autowired           // 컨테이너가 만든 진짜 빈을 주입
    MemberService memberService;

    @Test
    void 회원가입_통합() {
        Member saved = memberService.join(new Member(1L, "kim"));
        assertThat(memberService.find(1L)).isEqualTo(saved);
    }
}

#5. 컨트롤러 테스트 — @WebMvcTest + MockMvc { #5-controller-test }

컨트롤러의 요청 매핑·응답만 가볍게 검증하려면 웹 계층만 띄우는 @WebMvcTest와, 실제 서버 없이 HTTP 요청을 흉내 내는 MockMvc를 쓴다.

@WebMvcTest(MemberController.class)   // 웹 계층만 로딩 (가벼움)
class MemberControllerTest {

    @Autowired MockMvc mockMvc;       // 가짜 HTTP 요청 도구

    @MockitoBean MemberService memberService;  // 의존 서비스는 목으로 대체

    @Test
    void 회원목록_페이지() throws Exception {
        mockMvc.perform(get("/members"))     // GET /members 요청 흉내
               .andExpect(status().isOk())   // 200 OK 인가
               .andExpect(view().name("members/list"));
    }
}