Test Driven Develop(TDD)

TDD 테스트 기반 개발

• 작성해야 하는 프로그램에 대한 테스트를 먼저 수행하고 이 테스트를 통과할 수 있도록 실제 프로그램의 코드를 작성한다는 원리
• 테스트 케이스를 작성하고 소스 코드가 이를 통과하는지 반복확인하며 프로젝트를 진행하는 것
• 짧은 개발 주기의 반복에 의존하는 개발 프로세스이며, 애자일 방법론 중 하나인 eXtream Programming(XP)의 ‘Test-First’ 개념에 기반을 둔 단순한 설계를 중요시한다.
• 기능의 구현 목표에 집중하여 개발 생산성을 높이고, 이후 발생할 Refactoring을 지속할 수 있게 하는 근간이 되기도 함

---

XP(eXtream Programming)

• 미래에 대한 예측을 최대한 하지 않고 지속적으로 프로토타입을 완성하는 애자일 기방법론 중 하나
• 의사소통 개선과 즉각적 피드백으로 소프트웨어 품질을 높이기 위한 방법론
• 추가 요구사항이 생기더라도 실시간으로 반영할 수 있음

 

단위 테스트(unit Test)

• 한 단위(일반적으로 class)만을 테스트하는 것

출처: HANAMON,  TDD란? 테스트 주도 개발 / TDD의 개발주기 표현

TDD 개발주기

• Red 단계: 실패하는 테스트 코드를 먼저 작성
• Green 단계: 테스트 코드를 성공시키기 위한 실제 코드를 작성
• Blue 단계: 중복 코드 제거, 일반화 등의 리팩토링을 수행
  • 중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과
  • 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야하는 것
  • -> 실제 코드에 대해 기대되는 바를 보다 명확하게 정의 함으로써 불필요한 설계를 피할 수 있고
  • -> 정확한 요구 사항에 집중할 수 있음

---

일반 개발 방식과 TDD 개발 방식의 비교

일반 개발 방식

• 보통 개발 방식은 요구사항 분석 → 설계 → 개발 → 테스트 → 배포의 형태의 개발 주기
• 보통 개발 방식: 소프트웨어 개발을 느리게 하는 잠재적 위험이 존재

 

 

출처: HANAMON,  TDD란? 테스트 주도 개발

 

보통 개발 방식이 소프트웨어 개발을 느리게 하는 이유

 

1. 소비자의 요구사항이 처음부터 명확하지 않을 수 있음 -> 처음부터 완벽한 설계는 어려움
2. 자체 버그 검출 능력 저하 또는 소스코드의 품질이 저하될 수 있음 -> 자체 테스트 비용이 증가
   • 이러한 문제점이 발생되는 이유는 어느 프로젝트든 초기 설계가 완벽하다고 말할 수 없기 때문
3. 고객의 요구사항 또는 디자인의 오류 등 많은 외부 또는 내부 조건에 의해 재설계하여 점진적으로 완벽한 설계로 나아감
4. 재설계로 인해 개발자는 코드를 삽입, 수정, 삭제하는 과정에서 불필요한 코드가 남거나 중복처 될 가능성이 큼

결론적으로 이러한 코드들은 재사용이 어렵고 관리가 어려워서 유지보수를 어렵게 만듬

• 작은 부분의 기능 수정에도 모든 부분을 테스트해야 하므로 전체적인 버그를 검출하기 어려워짐
  • -> 자체 버그 검출 능력이 저하됨
    • -> 어디서 버그가 발생할지 모르기 때문에, 잘못된 코드도 고치지 않으려 하는 현상이 나타나게 됨
• 이 현상은 소스코드의 품질 저하와 직결됨: 작은 수정에도 모든 기능을 다시 테스트해야하는 문제가 발생하여 자체 테스트 비용이 증가됨

---

TDD 개발 방식

• TDD와 일반적인 개발 방식의 가장 큰 차이점은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 것
• 디자인(설계) 단계에서 프로그래밍 목적을 반드시 미리 정의해야만 하고, 무엇보다 테스트해야 할지 미리 정의(테스트 케이스 작성)해야만 함
• 테스트 코드를 작성하는 도중 발생하는 예외 사항(버그 및 수정사항)은 테스트 케이스에 추가하고 설계를 개선함
• 이후 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성
• 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선됨으로 재설계 시간이 절감됨

출처: HANAMON,  TDD란? 테스트 주도 개발

이러한 반복적인 단계가 진행되면서 자연스럽게 코드의 버그가 줄어들고 소스코드는 간결해짐

---

TDD의 대표적인 Tool ‘JUnit’

JUnit

• 현재 전 세계적으로 가장 널리 사용되는 Java 단위 테스트 프레임워크
• 자바 프로그래밍 언어용 단위 테스트 도구

 

xUnit

• 자바의 단위 테스팅 프레임워크인 JUnit만 있는 것이 아님
• 다른 언어도 단위 테스트를 위한 프레임워크가 존재하며 보통 이름을 xUnit이라 지칭함
• 자바(Junit), C++(Cppunit), Net(Nunit) 등 다양한 언어를 지원하는 단위테스트 프레임워크
• 소프트웨어의 함수나 클래스 같은 서로 다른 구성 원소(단위)를 테스트할 수 있게 해주는 도구

---

TDD 개발 방식의 장점

보다 튼튼한 객체 지향적인 코드 생산

• TDD는 코드의 재사용 보장을 명시 -> TDD를 통한 소프트웨어 개발 시 기능 별 철저한 모듈화가 이뤄짐
• 이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 함
• 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치치 않게 됨

 

재설계 시간의 단축

• 테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게됨
• 테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해 볼 수 있음
• 개발 진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있음

 

디버깅 시간의 단축

• 유닛 테스팅을 하는 이점
• ex. 데이터가 잘못 나온다면 DB의 문제, 비즈니스 레이어의 문제, UI의 문제
• 실제 모든 레이어들을 전부 디버깅 해야하지만, TDD의 경우 자동화 된 유닛 테스팅을 전제하므로 특정 버그를 손쉽게 찾아낼 수 있음

 

테스트 문서의 대체 가능

• 주로 SI 프로젝트 진행 과정에서 어떤 요소들이 테스트 되었는지 테스트 정의서를 만듬 -> 단순 통합 테스트문서에 지나지 않는다
• TDD를 하게 될 경우: 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출 할 수 있음

 

추가 구현의 용의함

• 개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점: 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것
• TDD의 경우: 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있음

---

TDD 개발 방식의 단점

가장 큰 단점은 바로 생산성 저하

• 개발 속도가 느려진다고 생각하는 사람이 많기 때문에 TDD에 대해 반신반의함
  • 처음부터 2개의 코드를 짜야하고 중간중간 테스트를 하면서 고쳐나가야하기 때문
• TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어남
• SI 프로젝트에서는 소프트웨어의 품질보다는 납기일 준수가 훨씬 중요하기 때문에 TDD 방식을 잘 사용하지 않음

---

TDD를 하기 어려운 이유

이제까지 자신이 개발하던 방식을 많이 바꿔야 함

• 몸에 체득한 것이 많을 수록 바꾸기 어려움
• 오히려 개발을 별로 해보지 않은 사람들에겐 적용하기가 쉬움

산업경영공학과 ERP 수업 때 배운 Business process reengineering(BPR)이 생각남

 

TDD는 이렇게 해야된다는 이미지(틀)이 존재

• 반드시 툴(단위 테스트 프레임워크)을 써서 개발해야 된다. 라고 생각함: 이러한 규칙에 얽매이는 것은 애자일 방식이 아님
• copy&paste: 결국엔 규칙에 얽매여 똑같은 테스트 함
• 도구/규칙에 집착하다 보니 TDD가 어려워짐

---

TDD를 잘하는 방법

계속해서 본인이 일하는 방식을 업그레이드 해야 함

• ex. 게임을 개발하면서 stage 3를 테스트 할 때, 항상 stage 1, stage 2를 클리어한 뒤 테스트를 해야함
• -> 테스트 비용이 증가

 

어떻게하면 비용을 줄일 수 있을까?

• -> 바로 stage 3으로 갈 수 있도록 만듬: 피드백을 좀 더 저렴하게 자주 받을 수 있음
• Back Door 접근법 : 테스트 할 때 파라미터를 적용하여 본인이 원하는 시스템의 시작점으로 가게하는 것
• 중복적으로 하는 노력들을 자동화하도록 업그레이드하면 발전 할 수 있음

 

---

참고자료

수제비 정보처리기사 실기 1-6,0 5-39, 8-18

코드 품질을 높여주는 테스트 주도 개발 알아보기

선택이 아닌 필수 TDD

TDD란?

[기술면접] TDD(Test-Driven-Development) 방법론에 대해서

[Agile] TDD(테스트 주도 개발)란 – Heee’s Development Blog

HANAMON, TDD란? 테스트 주도 개발

요즘IT, 효율적인 Junit 사용방법과 유용한 팁