TDD에 대한 간략한 개요와 적용사례

1. Test-Driven Development
TDD의 개요와 활용예시
기술연구소 송진호

2. 기존 개발방법론의 문제점
. 설계 시 구현작업의 난이도 예측의 어려움
. 설계 및 요구사항 변경에 따른 대응이 어려움
. 완성된 결과물이 고객의 요구를 충족하지 못함.

3. 애자일 선언
절차와 도구를 넘어선 개성과 화합
문서화를 넘어선 동작하는 소프트웨어
계약과 협상을 넘어선 고객과의 협력
계획 준수를 넘어서 변화에의 대응
새로운 개발방법론이 아닌
새로운 가치와 철학

4. 그래서 애자일(Agile)
. 1. 날렵한, 민첩한 2. (생각이) 재빠른, 기민한
. 문서가 아닌 코드에 기반한 개발
. 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며, 요구를 더하고 수정
하는 점진적인 개발
. 익스트림 프로그래밍, 스크럼, FDD

5. TDD Overview
. Test-FirstDevelopment
. 보다 명확한 프로그래밍 목적을 디자인 단계에서 반드시 정의하고, 무엇을 테스
트 해야할지 미리 정의한다

6. 어떻게?
. 실패를 포함하는 테스트 코드의 작성
. 앞서 작성된 코드를 통과 할 수 있는 ‘최소한의 구현 코드’ 작성
. 구현 코드에 대한 리팩토링
. 테스트코드 작성 - 최소한의 구현코드 - 리팩토링 주기를 반복

7. 왜, TDD 인가?
1.목표의 구체화
2.짧은 개발 패턴을 통한 리듬
• 짧고 명확한 문제정의로 집중력 향상
• 테스트 코드를 통과하는 구현체 코드작성은 개발자에게 성취감을 줌
3.테스트 코드는 그 자체로 매뉴얼, 혹은 API 문서
• 점점 거짓말을 하는 문서 vs 살아있는 문서
4.개발하고 있는 코드의 문제점을 빠르게 잡아낼 수 있음

8. 오해 - 결과적으로 비용은 더 들고, 개발기간이 길어진다?
• 테스트와 테스트 자동화를 지원하는 프레임워크에 대한 추가적인 학습
└> 모든 프레임워크의 도입은 추가적인 학습 및 시간이 필수.
• 테스트코드 추가 작성으로 인해 결과적으로 작성해야 하는 코드 증가
└> 실제 코드를 작성하는 시간보다, 변경사항 반영, 디버깅 등에 시간을 더
투자하는 많은 경우가 많음. 이를 개선하고 예방하는 측면에서 감수할 수 있는
투자

9. TDD의 함정
• 테스트의 오버헤드
• 모든 코드의 테스트코드 작성을 의무화하고, 쓸데없는 테스트케이스 작성에 시간을
빼앗기게되는 상황 유발
• 설계를 망치는 TDD
• 유닛테스트를 작성하기 쉬운 설계를 은연 중에 강요. 시스템을 횡단하는 기능을 기피하게해서
설계를 기형적으로 만들 수 있음

10. 예시
TDD를 통한 ArkSQL Library 구현

11. Q&A