[TDD 시리즈 2/2] Spring에서 TDD로 코딩해보기 – 포인트 사용 도메인 예제

Spring에서 TDD로 코딩해보기 – 포인트 사용 도메인 예제

---

1. 들어가며

앞선 글에서는
TDD의 개념과 특징, 장단점, 그리고 면접 질문을 중심으로
TDD를 이론적으로 정리했다.

이번 글에서는
Spring 환경에서 사용되는 도메인 로직을 예제로 삼아
TDD의 Red–Green–Refactor 흐름을 직접 코딩으로 실습해본다.

완성도 높은 구조나 실무 아키텍처를 만드는 것이 목적은 아니다.
TDD가 어떤 사고 흐름으로 코드를 만들어가는지 이해하는 것이 목표이다.

 

---

2. 실습 예제 설명

이번 실습에서는
포인트를 사용하는 간단한 도메인 로직을 예제로 사용한다.

이 예제는
정책과 분기가 명확하며,
TDD의 핵심 흐름을 이해하기에 적합하다.

요구사항

• 포인트를 사용한다.
• 보유 포인트보다 많은 금액을 사용하면 예외가 발생한다.
• 포인트 사용 시 잔액이 차감된다.

---

3. Red 단계 – 실패하는 테스트 작성

TDD의 시작은
기능 구현이 아니라 테스트 작성이다.

@Test
void 포인트를_사용하면_잔액이_차감된다() {
    Point point = new Point(1000);
    point.use(300);

    assertThat(point.getBalance()).isEqualTo(700);
}

이 시점에서는
Point 클래스가 아직 존재하지 않는다.

테스트는 컴파일 에러 또는 실패 상태이며,
이는 정상적인 Red 단계이다.

이 테스트는 다음 요구사항을 명확히 표현한다.

• 초기 포인트는 1000이다.
• 300을 사용한다.
• 결과 잔액은 700이어야 한다.

---

4. Green 단계 – 테스트를 통과시키는 최소 구현

이제 테스트를 통과시키는 코드를 작성한다.
이 단계의 목표는 오직 테스트 통과이다.

public class Point {

    private int balance;

    public Point(int balance) {
        this.balance = balance;
    }

    public void use(int amount) {
        balance -= amount;
    }

    public int getBalance() {
        return balance;
    }
}

이 코드는 구조적으로 완벽하지 않다.
검증 로직도 존재하지 않는다.

그러나 테스트는 통과한다.
Green 단계에서는 코드의 품질보다 테스트 통과가 우선이다.

---

5. Red 단계 – 예외 케이스 테스트 추가

다음 요구사항을 테스트로 추가한다.

 

보유 포인트보다 많은 금액을 사용하면 예외가 발생해야 한다.

@Test
void 보유_포인트보다_많이_사용하면_예외가_발생한다() {
    Point point = new Point(1000);

    assertThatThrownBy(() -> point.use(1500))
        .isInstanceOf(IllegalArgumentException.class);
}

이 테스트는 현재 코드 기준으로 실패한다.
다시 Red 상태가 된다.

---

6. Green 단계 – 예외 처리 최소 구현

테스트를 통과시키기 위해
최소한의 검증 로직을 추가한다.

public void use(int amount) {
    if (amount > balance) {
        throw new IllegalArgumentException("포인트 부족");
    }
    balance -= amount;
}

테스트는 다시 통과한다.
요구사항은 충족되었다.

---

7. Refactor 단계 – 구조 개선

이제 리팩토링을 진행한다.
테스트 코드는 변경하지 않는다.

public void use(int amount) {
    validate(amount);
    balance -= amount;
}

private void validate(int amount) {
    if (amount > balance) {
        throw new IllegalArgumentException("포인트 부족");
    }
}

• 검증 책임을 메서드로 분리한다.
• 가독성과 확장성을 개선한다.
• 테스트는 그대로 유지된다.

이 단계에서
테스트는 리팩토링의 안전망 역할을 한다.

---

8. 핵심 정리

• 테스트는 요구사항을 코드로 표현한다.
• 구현은 테스트에 의해 방향이 결정된다.
• 리팩토링은 테스트가 있을 때 안전하게 수행할 수 있다.
• 처음부터 완벽한 설계를 만들 필요는 없다.

TDD는
한 번에 좋은 설계를 만드는 방식이 아니다.
테스트를 통해 설계를 점진적으로 다듬는 방식이다.

---

9. TDD 적용 기준

• 모든 코드에 TDD를 적용하지 않는다.
• 정책과 분기가 많은 도메인 로직에 우선 적용한다.
• 단순 CRUD나 화면 중심 로직은 테스트 후행으로 처리한다.
• 핵심 유스케이스 위주로 점진적으로 확장한다.

---

10. 마무리

TDD는
테스트를 먼저 작성하는 기술이 아니다.

코드를 작성하기 전에
한 번 더 생각하게 만드는 개발 방식이다.

이번 실습을 통해
TDD의 전체 흐름과 의도를 이해했다면,
Spring 기반 실무 코드에서도 충분히 부분 적용이 가능하다.

 

 

2026.01.05 - [IT/Backend] - [TDD 시리즈 1/2] TDD란 무엇인가, 개념, 특징, 장단점, 면접 질문 정리

[TDD 시리즈 1/2] TDD란 무엇인가, 개념, 특징, 장단점, 면접 질문 정리