[TDD/방법론] 자네, TDD가 뭔지 아는가?

🙋🏻‍♀️TDD와의 첫 만남.

작년 겨울, 처음 만난 TDD는 나에게 정말 새로운 경험이었다.
어쩌면 이 글을 읽는 누군가는 TDD를 이 글로 인해 처음 알게 될 수도 있을 것이다.

TDD / BDD / DDD
위 세가지에 관해 정리한 글은 여기에 있다.

개발자라면 어디선가 한번 쯤은 들어봤을 용어들.
그치만 생각보다 테스트 코드를 도입하지 않은 회사가 많다. (일단 현재 회사)

여기저기서 이렇게 많이 떠들고 강조하는 걸 보니 중요한거같은데!
"당장 쓰든, 안 쓰든 지대넓얇(지적인 대화를 위한 넓고 얕은 지식)을 쌓아보자!" 가 이 글의 취지이다.

이전에 썼던 개념들도 정리하고, TDD도입의 사례를 보며 'TDD도입이 정말 좋은 선택인걸까?' 에 대해 함께 고민하는 시간을 가졌으면 좋겠다.

✅ TDD가 뭘까?

TDD(Test Driven Development) : 테스트 주도 개발
반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.
개발 시작하기 전에 테스트 케이스를 먼저 작성하고, 이 테스트 케이스를 통과하는 코드를 작성하는 방법론이다.

말 그대로 우리는 그동안 기능에 대한 구현 > 테스트 코드 작성해서 잘 되는지 확인!
이었다면 TDD는
기능에 대해 뼈대를 만들고 테스트를 통과하면 실제 코드에 작성 > 조금 더 작은 단위의 테스트코드 작성 > 통과하면 실제 코드에 적용 의 과정을 반복하는 것이다.

📌 TDD의 핵심 과정

1. 테스트 코드 작성

• 요구사항을 기반으로 테스트를 먼저 작성한다.
• 잘 실패하는 코드를 만든다.

2. 실제 코드 작성

• 테스트를 통과할 최소한의 코드를 작성한다.

3. 리팩토링

• 중복 제거 및 코드 개선
• 유지보수하기 쉽게 다듬는다.
• 성능 최적화가 가능하다.
• 리팩토링 후에도 기존 테스트가 통과해야한다.

위 과정을 반복하며 코드 품질과 안정성을 보장하는 방식이다.

// 1️⃣ 실패하는 테스트 작성
@Test
void addNumbers_shouldReturnSum() {
    Calculator calculator = new Calculator();
    assertEquals(5, calculator.add(2, 3)); // ❌ Calculator 클래스가 없으므로 컴파일 에러
}

// 2️⃣ 최소한의 코드 작성 (클래스만 생성, 메서드 구현 X)
public class Calculator {}

// 3️⃣ 실패하는 테스트 (메서드가 없어서 컴파일 에러는 해결되지만 여전히 실패)
public class Calculator {
    public int add(int a, int b) { 
        return 0; // 임시로 0 반환 -> 실패 유지
    }
}

// 4️⃣ 테스트를 통과하도록 최소한의 코드 작성
public class Calculator {
    public int add(int a, int b) {
        return a + b; // ✅ 이제 테스트 통과!
    }
}

⭐️ TDD의 특징과 장점

1. 버그 발견이 빠르다.

• 기능 구현하기 전에 테스트를 먼저 작성하기 때문에 버그를 사전에 방지할 수 있다.
• 예측하지 못한 오류를 줄일 수 있다.

2. 설계 품질이 향상된다.(유지보수성 향상)

• 테스트 코드가 자연스럽게 명확한 인터페이스를 설계하게 해준다.
• 코드가 모듈화되고, 단일 책임 원칙(SRP)이 적용되기 쉽다.

3. 안전한 리팩토링이 가능하다.

• 리팩토링 후에도 기존 테스트를 다시 실행하면서 정상동작 여부를 검증할 수 있다.
• 기능이 깨지는 것을 방지할 수 있다.

4. 개발 속도 증가

• 처음에는 개발 속도가 느려질 수 있지만, 버그 수정 시간 절약 효과가 크다.
• 배포 이후 버그 수정 비용이 줄어들어 전체 개발 생산성이 증가한다.

✅ Testable 한 코드란?

이전에 Testable한 코드에 대해 작성한 글이 있다.

요약하면,

• 몇번을 수행해도 항상 같은 결과가 반환되는 코드가 Testable 한 코드라고 할 수 있다.

🤚그럼 장점만 있는걸까?

이렇게 좋은 점만 나열해놨는데, TDD의 단점은 없는걸까?

1. 초기 개발 속도의 지연
   TDD는 "테스트 먼저" 접근 방식이기 때문에 처음 개발할 때 시간이 더 걸릴 수 있다.

• 기능 구현 전에 테스트를 먼저 작성해야 하기 때문에 초기 개발 속도가 느려질 수 있다.
• 빠르게 프로토타이핑해야 하는 스타트업 환경에서 부담이 될 수 있다.
• 개발 일정이 빠듯하면 TDD 적용이 어려울 수 있다.

💡 해결책:
- 모든 기능을 TDD로 개발할 필요는 없다. 중요한 핵심 로직이나 복잡한 비즈니스에 우선 적용한다.
- 익숙해지면 개발 속도가 점점 빨라진다는 점을 고려해야한다.

2. 테스트 코드 유지보수 필요.
   기능이 바뀔 때마다 테스트 코드도 함께 수정해야한다.

• 작은 기능 변경에도 관련된 테스트 코드가 깨질 수 있다. => 그치만 상관 없는 코드까지 너무많이 깨진다면? 테스트코드를 잘못 짠건 아닌지 확인해보자!
• 유지보수할 코드가 늘어나면서 개발자의 부담 증가.
• 너무 많은 테스트 코드작성은 테스트 자체가 복잡성을 증가시킬 수도 있다.

💡 해결책:
- 지나치게 세부적인 테스트 보다는 핵심 로직을 검증하는 테스트 집중하기.
- 테스트가 지나치게 구체적이면 유지보수가 어렵기 때문에 적절한 추상화 필요.

3. UI테스트와 같은 복잡한 테스트 적용이 어렵다.

• 백엔드 로직(비즈니스 로직, API, 서비스 레이어)에는 적합하지만,
  UI(프론트엔드)개발에서는 적용이 어렵다.
• 특히 비동기 처리, 애니메이션, 외부 API연동 같은 요소는 TDD로 관리하기 어렵다.

4. 모든 상황을 테스트하기 어렵다.

• 특히 멀티스레딩, 데이터베이스 트랜잭션, 네트워크 요청 같은 요소들은 실제 환경과 다를 수 있어서 테스트가 무의미해질 수도 있다.
• 외부 API를 호출하는 경우 Mocking이 필요하지만, 모든 상황을 Mocking하는 것도 쉽지 않다.

💡 해결책 :
- 통합 테스트와 병행하여 중요한 핵심 로직만 TDD로 관리하기.
- Mocking과 실제 테스트 데이터를 적절히 조합해서 테스트하기.

5. 개발팀의 TDD 숙련도가 중요.

• 단순히 테스트 코드를 먼저 작성하는게 아닌
  설계, 유지보수, 리팩토링까지 고려해야하는 방법론이다.
• 잘못된 설계유지나 과도한 테스트로 인해 개발 속도가 떨어질 수 있다.
• 팀 전체가 TDD를 이해하고 실천해야 효과가 나타나는데, 개발자마다 경험과 스타일이 다르다 보니 팀 내 통일이 어려울 수도 있다.

💁🏻‍♀️TDD 도입 사례

그럼 어디에 TDD를 도입 했을 때 도움이 되는걸까?
결제 시스템, 인증 시스템, API개발 등 실무에서 주요 비즈니스 로직에 적용될 수 있다.

특정 금융 서비스 회사는 TDD를 도입하여 개발 프로세스를 개선하고, 결함률을 크게 줄였다.
이 회사는 TDD를 통해 개발 초기 단계에서 오류를 발견하고 수정하여 전체적인 프로젝트의 지연을 방지하고, 고객만족도를 향상시켰다.

많은 오픈 소스 프로젝트들은 TDD방법론을 채택하여 개발 과정에서의 품질을 보장한다.
왜냐하면 TDD는 개발 과정에서 발생할 수 있는 오류를 사전에 예방하고, 유지보수가 용이한 코드를 작성할 수 있게 해주기 때문이다.

끝으로.

TDD 말만 많이 들어보고 실제 비즈니스에 적용해본 적이 없어서 '꼭 써야해? TDD 안써도 잘 돌아가지않나?' 라고 막연하게 생각했다.
많은 기업에서 안정적인 시스템을 강조하는 만큼 안정적인 비즈니스 로직을 구축하려면, 그리고 좋은 개발 문화를 갖기 위해서 도입하는게 여러모로 장점이 많은 것 같다.

---

TDD(Test-Driven Development)의 이해와 실제 적용 사례

올리브영 테크블로그 : W CARE 서비스 프론트엔드를 TDD로 개발해본 후기
카카오 페이 테크블로그 : 실전에서 TDD하기