테스트 코드, 대체 어떻게 쓰는걸까? 흐름을 따라가보자.

개요

애플리케이션을 개발하다보면 "내 코드가 정말 제대로 동작하고 있을까?"라는 의문이 들기 마련이다. 또한 시간이 지난 뒤에 코드를 리팩토링하거나 수정할 때, 기존 기능이 깨지지 않았는지도 확인해야한다.

그래서 테스트 코드는 단순한 선택이 아니라, 신뢰할 수 있는 소프트웨어를 만드는데 필수 요소라고 생각한다. 이번 글에서는 진행하고 있는 독서 모임 플랫폼 프로젝트의 Club 도메인을 예시로, 코틀린에서 테스트 코드를 어떻게 작성하는지 정리해보았다.

 

1. 테스트의 목적 

• 정상 동작 검증: 내가 작성한 코드가 예상대로 동작하는지 확인
• 실패 시그널: 기능이 변경되거나 고장났을 때 빠르게 감지
• 리팩토링 안전망: 내부 구현을 바꿔도 외부 동작이 같으면 안심하고 리팩토링 가능

 

2. 테스트의 기본 구성 (Given - When - Then)

테스트 시, 가장 많이 쓰는 패턴이다.

• Given: 테스트에 필요한 상황을 준비
• When: 테스트 대상 메서드를 실행
• Then: 기대 결과를 검증

@Test

fun `회원이 참여 요청을 보내면 요청 상태는 PENDING 이어야 한다`() {
   //Given
   val club = Club("제목", "설명", 5, hostId = 1)
   
   //when
   club.requestJoin(memberId = 2)
   
   //Then
   val requested = club.members.first { it.memberId == 2 }
   assertEquals(ClubMemberState.PENDING, requested.state)
}

 

3. 테스트 작성 흐름

1. 테스트하고 싶은 대상 메서드를 선택하고,
2. 다양한 상황(시나리오)을 나누어
3. 정상 케이스 + 예외 케이스 모두 작성한다. 
4. 테스트 이름은 가능하면 자연어 문장으로 써서 의도를 설명하듯이 짓자.

 

4. 테스트 코드 작성 규칙 

항목	설명
의도 표현	테스트 이름은 "무엇을 할 때 어떤 결과가 나와야 한다" 형태로 추천
assert 구문	결과가 기대한 값과 같은지 assertEquals, assertTrue, assertThrows 등 사용
작고 빠르게	테스트는 작고, 실행이 빨라야 자주 실행할 수 있음
경계 조건 테스트	0명, 최대 정원, 중복 등 edge 케이스도 꼭 테스트!
하나의 테스트는 하나의 검증만	너무 많은 것을 검증하면 실패 원인 파악이 어려워짐

 

5. 코틀린에서 테스트 도구

보통은 Junit5 기반으로 작성하며, 코틀린에서도 동일하게 사용할 수 있다.

 

주요 어노테이션

어노테이션	설명
@Test	테스트 메서드
@BeforeEach, @AfterEach	각 테스트 전/후 실행 코드
@Nested	계층적 테스트 구조
assertThrows	예외 발생 테스트
assertEquals, assertTrue, assertFalse	결과 검증용

 

6. 테스트를 잘 설계하기 위한 기준

기준	체크포인트
명확한 책임	테스트는 하나의 기능/조건만 검증하는가?
독립성	테스트끼리 서로 영향을 안주는가?
반복 가능성	어떤 환경에서도 항상 같은 결과를 내는가?
실패 명확성	실패 시 원인이 명확하게 드러나는가?
유지보수성	테스트도 읽기 쉽고 수정하기 쉬운가?

 

실제로 작성한 테스트 시나리오

현재 개발 중인 독서 모임 플랫폼의 Club 도메인에서는 아래와 같이 테스트 시나리오들을 작성해보았다.

• 생성자에 잘못된 값이 들어오면 예외를 던진다.
• 정원을 초과하면 참여 요청이 실패 한다.
• 이미 요청한 멤버는 중복 요청 할 수 없다.
• 호스트가 아닌 사람이 승인 요청을 하면 예외가 발생한다.

 

마무리

처음에는 테스트 코드를 작성하는게 귀찮고 어렵게 느껴질 수 있지만, 테스트는 코드의 품질에 있어서 굉장히 중요한 요소이다. 이번에 정리한 흐름을 바탕으로, 이후에 작성하는 도메인들도 테스트 먼저 작성하고 개발하는 습관을 가져보려한다. 화이팅!!