[10분 테코톡] 😼 피카의 TDD와 단위테스트

출처: https://www.youtube.com/watch?v=3LMmPXoGI9Q

📌 TDD(테스트 주도 개발)와 단위 테스트는 무엇이며, 왜 사용해야 하는가?

TDD는 테스트 코드를 먼저 작성하고 프로덕션 코드를 나중에 만드는 개발 방법이며, 단위 테스트는 코드의 가장 작은 단위를 검증하여 코드의 안정성과 품질을 높이는 절차입니다.

💡 TDD의 진정한 장점은 무엇인가?

• 자연스러운 테스트 커버리지 증가
• 오버 엔지니어링 방지
• 설계에 대한 빠른 피드백 제공

---

배경지식: TDD와 단위 테스트, 그리고 개발 문화

이 노트는 에서 다루는 TDD(테스트 주도 개발)와 단위 테스트를 처음 접하는 분들이 내용을 100% 이해할 수 있도록 돕기 위해 작성되었습니다. 특히 TDD의 배경, 그 창시자의 의도, 그리고 좋은 테스트를 만들기 위한 구체적인 원칙을 쉽게 풀어 설명합니다.

1. TDD의 창시자, 켄트 벡(Kent Beck)과 근본적인 이유

TDD(Test-Driven Development)는 단순히 '테스트 코드를 먼저 작성하는 것' 이상의 철학을 담고 있습니다. 이 방법론을 창시한 켄트 벡은 프로그래밍의 근본적인 문제, 즉 두려움(Fear)을 해결하기 위해 TDD를 제안했습니다.

• 켄트 벡의 정체:
  • 켄트 벡은 익스트림 프로그래밍(XP)의 창시자 중 한 명이며, 소프트웨어 개발 분야의 선구자로 꼽힙니다. 그는 개발자들이 코드를 변경하거나 추가할 때 느끼는 불안감을 줄이는 데 집중했습니다.
  • 그는 TDD를 통해 개발자들이 코딩 결정 하나하나에 대한 피드백을 즉각적으로 얻고 , 궁극적으로 개발의 두려움을 제거하는 것을 목표로 했습니다 .
• TDD의 핵심 사이클 (Red-Green-Refactor):
  • TDD는 다음과 같은 세 단계의 순환 구조를 반복하며 진행됩니다 . 이 사이클을 지키는 것이 TDD의 핵심입니다.

• TDD의 장점 (Why We Use TDD):
  • 디버깅 시간 절감: 테스트가 특정 기능의 오류 지점을 바로 알려주기 때문에, 문제가 발생한 부분을 빠르게 확인할 수 있습니다 .
  • 오버 엔지니어링 방지: 요구사항에 딱 맞는 테스트를 먼저 작성하기 때문에, 미래에 필요할지 모르는 불필요한 코드를 미리 만들지 않게 됩니다 (오버 엔지니어링 방지) .
  • 동작하는 문서 역할: 테스트 코드가 곧 프로덕션 코드가 '어떻게 동작해야 하는지'를 보여주는 가장 확실한 문서가 됩니다 .

2. '10분 테코톡'의 맥락과 이규원의 논쟁

원본 자료는 '우아한 테크코스(우테코)' 교육 과정의 일환인 '테코톡'입니다. 이는 교육생들이 지식을 공유하는 발표 세션입니다. 따라서 발표자인 피카(Pika)님은 이 교육 과정을 경험한 개발자로서 실질적인 노하우를 공유하고 있습니다.

• 우아한 테크코스(우테코) 배경:
  • 우테코는 배달의민족을 운영하는 우아한형제들에서 운영하는 개발자 교육 프로그램으로, 자기주도 학습, 페어 프로그래밍, TDD, 코드 리뷰 등을 통해 품질 좋은 코드를 작성하는 연습을 중시합니다 .
  • 이러한 배경 때문에, 이 자료는 단순히 이론이 아닌 실제 교육 환경에서 체득한 TDD 경험과 그 어려움을 다루고 있습니다.
• TDD는 설계 방법론인가? 논쟁의 배경:
  • 영상에서 "TDD는 설계 방법론이 아니다"라는 이규원 님의 발언이 인용됩니다 . 이 논쟁은 TDD에 대한 실무적인 이해를 높이는 중요한 지점입니다.
  • 이규원 님은 OKKYCON 2018 등에서 TDD의 현실적인 적용과 실패 이유에 대해 강연한 바 있는 개발 전문가입니다.
  • 그의 핵심 주장은 TDD 자체가 '좋은 설계'를 보장하지는 않는다는 것입니다. TDD를 성공적으로 적용하려면, 높은 응집도와 낮은 결합도와 같은 설계 기법(SOLID 원칙 등)이 먼저 도입되어야 합니다 .
  • 실패하는 TDD: TDD가 실패하는 흔한 이유는 구현체에 의존적인 테스트를 작성하기 때문입니다. 인터페이스나 요구사항 대신, 내부 구현 방식을 테스트하면 코드를 리팩토링할 때마다 테스트가 깨지는 문제가 발생합니다 .

3. 좋은 코드를 위한 두 가지 원칙: SOLID와 FIRST

단위 테스트를 효과적으로 수행하고, TDD를 통해 좋은 설계를 유도하기 위해서는 두 가지 핵심 원칙을 이해해야 합니다.

3.1. TDD가 추구하는 좋은 설계 (SOLID 원칙)

TDD가 직접적으로 SOLID 원칙을 강제하지는 않지만 , TDD를 통해 얻으려는 '좋은 설계'는 궁극적으로 SOLID 원칙을 지향합니다. SOLID는 객체 지향 설계의 5가지 핵심 원칙의 약자입니다.

원칙	영어 풀네임	핵심 설명	TDD와의 연결점
S	Single Responsibility Principle	하나의 클래스는 오직 하나의 책임만 가진다.	클래스나 메서드가 너무 많은 일을 하면 테스트 코드 작성이 복잡해져 TDD가 어려워진다 .
O	Open/Closed Principle	확장에 열려 있고, 수정에 닫혀 있어야 한다.	새로운 기능을 추가할 때 기존 코드를 건드리지 않으므로 안정성을 확보할 수 있다.
L	Liskov Substitution Principle	자식 클래스는 부모 클래스로 대체 가능해야 한다.	다형성을 올바르게 활용하여 유연한 구조를 만든다.
I	Interface Segregation Principle	클라이언트는 자신이 사용하지 않는 인터페이스에 의존하지 않아야 한다.	인터페이스의 일관성을 높이고 테스트 단위 분리를 쉽게 한다.
D	Dependency Inversion Principle	추상화에 의존해야 하며, 구체화에 의존하면 안 된다.	높은 수준의 모듈(인터페이스)을 테스트하여 구현체가 변경되어도 테스트가 깨지지 않게 한다.

3.2. 좋은 단위 테스트의 조건 (FIRST 원칙)

에서 좋은 단위 테스트의 조건으로 언급된 항목들은 FIRST라는 약자로 정리할 수 있습니다. 이는 단위 테스트가 가져야 할 5가지 덕목입니다.

• Fast (빠르게, Fast)
  • 테스트는 컴퓨터처럼 매우 빠르게 실행되어야 합니다. 테스트가 느리면 자주 실행하지 않게 되고 , 결국 코드 품질이 나빠집니다.
• Independent (독립적으로, Independent)
  • 각 테스트는 서로 의존해서는 안 됩니다. 한 테스트의 결과가 다른 테스트에 영향을 주면 안 됩니다.
  • 만약 의존성이 있다면, 하나가 실패할 때 도미노처럼 모든 테스트가 실패하여 실패 원인을 진단하기 어렵습니다.
• Repeatable (반복 가능하게, Repeatable)
  • 테스트는 어떤 환경(개발 환경, 테스트 서버, 인터넷이 끊긴 환경 등)에서도 항상 동일한 결과를 내야 합니다 .
• Self-Validating (자가 검증, Self-Validating)
  • 테스트는 결과를 사람이 주관적으로 판단할 필요 없이, 성공(True) 또는 실패(False)의 불린 값으로 명확하게 결과를 반환해야 합니다 .
• Timely (적시에, Timely)
  • 테스트 코드는 프로덕션 코드를 구현하기 직전에 작성되어야 합니다 . 코드를 다 짜고 나서 테스트를 만들면, 코드가 테스트하기 어렵게 되어 결국 코드를 다시 짜야 할 수도 있습니다 .

---

1. TDD(테스트 주도 개발)의 정의와 개발 사이클

1.1. TDD의 개념 및 개발 프로세스

1. TDD의 정의: TDD는 테스트 주도 개발(Test Driven Development)의 약자로, 프로그램 작성 전에 테스트 코드를 먼저 작성하고 실제 프로덕션 코드를 나중에 만드는 개발 방법이다.
2. TDD의 창시자: TDD의 창시자인 켄트 벡(Kent Beck)은 프로그램을 작성하기 전에 테스트를 먼저 하라고 강조했다.
3. 기존 프로세스와의 차이:
   1. 기존 프로세스: 설계 → 개발 코드 작성 → 테스트 코드 작성 순서이다.
   2. TDD 프로세스: 테스트 코드를 먼저 작성한 후 개발 코드를 작성한다.
4. TDD 개발 사이클 (레드, 그린, 리팩터): TDD는 세 가지 사이클로 이루어져 있다.
   1. 레드 (Red): 테스트를 실패하는 단계이다.
   2. 그린 (Green): 테스트를 성공할 수 있도록 프로덕션 코드를 구현하는 단계이다.
   3. 리팩터 (Refactor): 프로덕션 코드와 테스트 코드를 리팩토링하는 단계이다.

1.2. TDD를 사용하는 이유와 장점

1. 일반적으로 알려진 TDD의 장점:
   1. 개발에 대한 두려움을 줄여준다.
   2. 디버깅 시간을 줄여준다.
   3. 동작하는 문서 역할을 한다.
2. 테스트 커버리지 향상: 테스트 코드를 먼저 작성하므로 자연스럽게 테스트 커버리지가 높아진다.
   1. 테스트 코드 작성을 미루거나 하지 않는 경험을 방지해 준다.
3. 오버 엔지니어링 방지:
   1. TDD를 수행하면 요구사항에 맞춰 개발 코드를 구현하므로, 딱 필요한 만큼만 코딩할 수 있다.
   2. 미래에 필요할 것 같은 기능을 짐작하여 불필요한 코드를 작성하는 오버 엔지니어링을 방지해 준다.
4. 설계에 대한 빠른 피드백:
   1. 설계를 처음부터 잘하면 좋지만, 잘못 설계했을 경우 문제가 발생하거나 사용하기 어려울 때 비로소 깨닫게 된다.
   2. TDD는 테스트 코드를 작성하는 과정에서 복잡하거나 잘못된 설계를 가지고 있으면 테스트 코드 작성이 어려워지는 것을 통해 빠르게 설계에 대한 피드백을 제공하며, 이를 통해 설계를 빠르게 바꿀 수 있다.

1.3. TDD가 설계 방법론이 아닌 이유

1. TDD의 역할 한계: TDD가 설계 방법론이라면 TDD를 통해 좋은 설계를 얻을 수 있어야 한다.
2. TDD가 제공하지 않는 것: TDD는 다음과 같은 설계 원칙에 대한 어떠한 신호도 주지 않는다.
   1. 높은 응집도(Cohesion)
   2. 단일 책임 원칙(SRP)
   3. 개방-폐쇄 원칙(OCP)
   4. 인터페이스 분리 원칙(ISP)
   5. 인터페이스의 일관성 노출
   6. 리팩토링 단계에서 좋은 구조를 안내하거나 강제하지 않는다.
3. TDD의 설계 영향: TDD는 설계에 전혀 영향을 미치지 않는 것은 아니며, 다음과 같은 역할을 수행한다.
   1. 간격과 의존성 형성을 억제하는 역할을 한다.
   2. OCP 위배를 경고하고 불명확한 설계 지점을 발견하는 데 도움을 준다.
4. 설계 의존의 위험성: 전적으로 TDD에만 의존하여 설계를 진행하면, 테스트하기에만 좋은 안 좋은 설계가 만들어질 수 있다.

2. TDD 실패의 일반적인 이유와 해결책: 인터페이스 테스트의 중요성

1. TDD 적용 실패의 원인: TDD를 적용하면서 실패하는 사람들이 많다.
   1. TDD를 실패하는 사람들은 일반적으로 코드가 이루고자 하는 가치나 기능을 테스트하기보다는, 그 기능을 어떻게 구현하고 있는지를 테스트한다.
2. 구현체 테스트의 문제점:
   1. 구현 방식을 테스트하면 테스트 케이스들이 구조적 결합도(Coupling)가 높아지는 결과를 초래한다.
   2. 결국 구현체를 리팩토링(내부 구현 변경)하면, 결합되어 있는 테스트 케이스들이 모두 깨지게 된다.
   3. 이는 테스트들이 구현체 내부의 Implementation에 존재하는 구체적인 구현체들을 테스트하고 있기 때문에 발생한다.
3. 해결책: 인터페이스 테스트:
   1. 구현체가 아닌 설계, 즉 인터페이스(Interface)를 테스트해야 한다.
   2. 인터페이스를 테스트하게 되면, 내부에 구현되어 있는 구현체를 리팩토링하더라도 테스트 케이스는 인터페이스를 테스트하기 때문에 깨지지 않는다.

   테스트 대상	특징	문제 발생 시
   구현체 (Implementation)	코드가 작동하는 방식 자체	내부 구조를 리팩토링하면 테스트가 우르르 깨짐
   인터페이스 (Interface)	코드가 외부에 노출하는 기능	내부를 리팩토링해도 테스트는 안정적임

3. 단위 테스트(Unit Test)의 개념과 목적

3.1. 단위 테스트의 위치와 정의

1. 전체 프로그램 테스트의 종류: 테스트는 크게 유닛 테스트(단위 테스트), 부분 기능 테스트, 통합 테스트가 존재한다.
2. 단위 테스트의 범위: 단위 테스트는 전체 테스트 중 제일 작은 단위이며, 코드 단위의 행위를 테스트한다.
3. 단위 테스트의 일반적인 절차: 일반적으로 메서드(Method) 레벨 테스트를 수행하며, 검증이 필요한 코드에 대해 테스트 케이스를 작성하는 절차이다.

3.2. 단위 테스트의 목적

1. 문제 지점 분리:
   1. 각 단위가 정확하게 동작하는지 검사하고, 문제가 발생했을 때 어디 부분이 잘못되었는지를 빨리 확인할 수 있게 해준다.
   2. 이를 통해 프로그램의 안정성이 높아지며, 이 안정성은 잠재적인 비용 절감으로 이어진다.
2. 변경 제어:
   1. 코드의 변화를 쉽게 파악할 수 있고, 수정된 코드가 정확하게 동작하는지 쉽게 알 수 있게 된다.
   2. 따라서 변경을 자주 할 수 있는 환경이 조성된다.
3. 테스트 개수 형성 (설계 피드백):
   1. 하나의 단위 테스트가 너무 크거나 복잡해지는 것은 코드에 잘못된 것이 있다는 신호로 간주할 수 있다.
   2. 테스트가 너무 많은 기능을 수행하고 있다면, 해당 코드가 리팩토링이 필요하다는 것을 바로 알 수 있다.
4. 코드의 문서화:
   1. 단위 테스트는 일명 샘플 코드라고도 불리며, 상호작용 및 의존 관계를 한눈에 파악할 수 있게 해준다.
   2. 단위 테스트는 배포되는 코드와 일치하므로 항상 최신 상태로 유지된다는 장점이 있다.
   

4. 좋은 단위 테스트를 만들기 위한 FIRST 원칙

4.1. FIRST 원칙의 구성 요소

1. F: Fast (빠르게):
   1. 테스트는 빨라야 한다.
   2. 테스트가 느리면 자주 돌릴 엄두를 내지 못하게 되고, 결국 문제를 빨리 찾아내 고치지 못하여 코드 품질이 망가지게 된다.
2. I: Independent (독립적으로):
   1. 각 테스트는 서로 의존하면 안 된다.
   2. 테스트가 서로 의존하게 되면 하나가 실패할 때 도미노처럼 나머지도 잇따라 실패하게 되어 원인 진단이 어려워지고, 내부의 결함이 숨겨지게 된다.
3. R: Repeatable (반복 가능하게):
   1. 테스트는 어떤 환경에서도 반복 가능해야 한다.
   2. 실제 환경, QA 환경, 심지어 네트워크가 연결되어 있지 않은 오프라인 환경에서도 실행할 수 있어야 한다.
   3. 테스트가 환경에 의존하게 되면 테스트 실패의 변명이 생기고, 환경이 준비되지 않아 테스트를 실행하지 못하는 상황이 발생한다.
4. S: Self-Validating (자가 검증하는):
   1. 테스트는 불린 값(Boolean)으로 결과를 내야 하며, 성공 아니면 실패를 무조건 반환해야 한다.
   2. 테스트가 스스로 성공과 실패를 판단하지 않는다면, 판단이 주관적으로 변하게 되고 지루한 수동 검증 작업이 필요하게 된다.
5. T: Timely (적시에):
   1. 테스트는 항상 적시에 작성해야 한다.
   2. 단위 테스트는 실제 코드를 구현하기 직전에 작성해야 한다.
   3. 실제 코드를 구현한 다음 테스트 코드를 만들게 되면, 실제 코드가 테스트하기 어렵다는 사실을 뒤늦게 발견할 수 있으며, 이 경우 구현한 코드를 다시 짜야 할 수도 있다.

원칙	내용	쉽게 설명하면?
Fast (빠르게)	테스트 실행 속도가 빨라야 합니다.	테스트가 느리면 자주 안 돌려보게 되고, 결국 코드 품질이 나빠집니다 .
Independent (독립적으로)	각 테스트는 서로에게 의존하면 안 됩니다.	하나가 실패했을 때 도미노처럼 줄줄이 실패하면, 진짜 원인을 찾기 어렵습니다 .
Repeatable (반복 가능하게)	어떤 환경에서도 (회사, 집, 심지어 인터넷 없는 환경에서도) 반복 실행 가능해야 합니다 .	환경 때문에 테스트가 실패할 수 있다면, 개발자가 테스트를 실행하지 않을 변명거리를 줍니다 .
Self-Validating (자가 검증)	테스트 결과는 반드시 성공(True) 또는 실패(False)로 명확히 나와야 합니다 .	사람이 주관적으로 결과를 판단하게 되면, 지루하고 비효율적인 수동 확인 작업이 필요합니다 .
Timely (적시에)	테스트는 실제 코드를 구현하기 직전에 작성해야 합니다 .	코드를 다 짜고 나중에 테스트를 만들면, 코드가 테스트하기 어렵게 짜여졌다는 사실을 너무 늦게 깨닫게 되어 다시 짜야 합니다 .