테스트 주도 개발 방법, TDD(Test-Driven Development)

TDD(Test-Driven Development)는 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나로 애자일 방법론중 하나이다. 일반적으로 개발을 먼저 수행하고, 테스트 단계를 거치는 방식을 관점을 뒤집은 것으로 테스트를 수행할 방법(ex: Test Case)을 먼저 만들고, 이 요건을 충족할 코드를 뒤에 짜는 것이다.

TDD는 이런 방식을 채용하였기 때문에, 더 고품질의 프로그램이 실현 가능해진다. 그리고 이어지는 리팩토링 단계는 테스트의 문제 뿐만 아니라, 코드의 단단함까지 더해질 수 있다. 결과적으로 TDD를 수행하게 되면 TC를 충족하는 코드와 군더더기 없는 코드(simple code 혹은 clean code)가 생산된다는 말이 된다.

일반적으로 개발을 진행하였을 때, 들어가는 노력과 시간은 단순히 어떤 알고리즘을 짜는 개발 단계가 아니라 버그를 수정하는 단계와 유지보수하는 단계에서 더 많은 비용이 들어가게 마련이다. TDD는 TC를 통과하는 코드를 짜기 때문에 결함이나 버그를 수정하는 단계가 대폭적으로 감소하고, 클린 코드를 지향하여 유지보수에도 매우 유용하며 개발자의 실력 향상도 덤으로 가져갈 수 있는 매우 강력한 개발 방법일 것이다.

---

테스트를 고려한 클린코드 개발방법, TDD

TDD(Test-Driven Development) 개념

- 테스트에 중점을 두고, 테스트를 선 작성하여 통과하는 코드를 후에 개발하는 Agile 개발 방법론

참고로 TDD는 XP를 만든 사람중 하나인 켄트 벡(Kent Beck, 1961년~)이 개발하거나 혹은 '재발견' 한 것으로 인정 받고 있는데 그는 TDD가 단순한 설계를 장려하고 자신감을 불어넣어준다고까지 말하였다.

Kent Beck

TDD의 필요성

• 코드 복잡도 감소 : Refactoring을 통한 clean code 지향
• Defect 감소 : TC를 통과하는 코드만 만들기 때문에 결함 발생률 감소
• 피드백 : 테스트를 자주 하기 때문에 내 코드에 대한 피드백을 직접적으로 체험
• 협력 : 테스트를 위해 필히 해야 할 협력을 자주 수행

- 결함 발생률 감소와 클린 코드로 인하여, 대규모 프로젝트 일수록 순수 개발 기간도 감소 가능

 TDD의 흐름도 및 구성요소

TDD의 흐름도

source, https://wikidocs.net/224

TDD의 구성요소

• 사용자 요구사항 : 테스트 케이스를 만들기 위한 기초, 이해 관계자 등이 User Story 작성
• 테스트 케이스 : 사용자, 테스터 등이 테스트 케이스를 디테일하게 작성
• 코드 작성 : 테스트를 수행 할 최소한의 코드를 생성
• 리팩토링 : 작성한 코드를 표준에 맞게 리팩토링 실행

Wikipedia(한국)는 중심이 되는 것을 테스트 케이스라고 하였지만, 점프 투 자바와 같은 책 같은 경우는 테스트 코드를 테스트 케이스 위치에 놓았다. 테스트 코드와 같은 경우 단위 테스트 단계에 활용되고, 테스트 케이스같은 경우는 단위 테스트보다는 통합, 시스템 테스트 단계에서 활용될 수 있지만 TDD에서는 테스트와 테스트 케이스를 분리할 필요 없이 하나로 보는 것도 편할 것이다. TDD가 나온 개념이 2000년대 초이기 때문에 현재 테스트 도구등에 대한 설명이 존재하지 않는 시절이라 그대로 가져와서 해석하기에는 무리가 있을 것이고, 단지 테스트를 먼저 통과하는 코드를 만들고 그 이후 리팩토링을 한다는 개념만 가져오면 TDD라는 큰 틀을 벗어나지 않을것이라 생각한다.

TDD의 사용패턴

• 빨강막대 패턴 : 테스트를 언제, 어디에 작성할 것이며 언제 멈출 것인지 결정하는 패턴
• 초록막대 패턴 : 코드가 테스트를 통과하도록 신속하게 동작하는 코드 작성
• 테스트 패턴 : 상세한 테스트 작성 (자식/모의객체/메시지 호출)
• 디자인 패턴 : 검증된 해결책, Best Practice
• xUnit 패턴 : 자동화된 단위 테스트를 지원하는 프레임워크(ex: jUnit, CppUnit, PyUnit)

예상 장애요소 및 해결 방안

예상 장애요소

구분	장애요소	설명
사용자요구	빈번한 요구사항 변경	- 과도한 테스트케이스 변경, 반복적인 소스코드 변경 수반
테스트설계	테스트 케이스의 독립성 확보 어려움	- 반복적인 소스코드의 변경은 테스트 케이스의 변경 유발 - 연관된 테스트 케이스에 영향
코드작성	유닛 테스트의 자동화툴 지원 및 툴의 유연성	- 자동화 되지 않을 경우 테스트 진행 증가로 개발주기 문제 발생 - 개발언어별 유닛 테스트 도구의 지원 부족 가능성
리팩토링	반복적인 회귀테스트	- 빈번한 TC 변경에 자동화 툴이 유연하고 신속하게 지원할 수 없을 경우 반복되는 테스트의 효율적 관리 어려움 - 지루하고 기계적인 과정으로 변질 가능

해결 방안

장애요소	제거방안	설명
요구변경	요구공학, 형상관리	- TDD는 빠른 개발을 목표로 하지만 대규모 시스템 적용 시에는 요구공학 등의 공학적인 요구사랑 관리 기법 필요
테스트 케이스	테스트 전문가 활용	- 독립된 QA조직의 운영은 개발자에 의해 이루어지는 단위 테스트 작업에서 발생할 수 있는 다양한 이슈 해결 가능
Unit 테스트	자동화 툴 사용	- jUnit, CppUnit 등과 같이 단위 테스트를 지원하는 자동화 툴을 사용하여 테스트 진행

참고자료

https://ko.wikipedia.org/wiki/%ED%85%8C%EC%8A%A4%ED%8A%B8_%EC%A3%BC%EB%8F%84_%EA%B0%9C%EB%B0%9C

BDD부터 TDD까지 다양한 애자일 기법의 장단점 - itworld

연관자료

비즈니스 요구에 빠른 대응의 가능한, XP(eXtreme Programming)