TDD 테스트 주도 개발

TDD(Test-Driven Development)

TDD는 테스트 주도 개발로 소프트웨어 개발 프로세스 중 하나다.

요구사항을 검증하는 자동화된 테스트 케이스를 먼저 작성하고, 테스트를 통과하기 위한 최소한의 코드를 작성한다. 마지막으로 표준에 맞게 작성한 코드를 리팩토링한다.

http://clipsoft.co.kr/wp/blog/tddtest-driven-development-방법론/

기존 프로세스는 [ 요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포 ] 의 사이클을 가지고 있는데, 소비자의 요구사항이 명확하지 않거나 수정사항이 생겼을 경우 설계를 처음부터 고쳐야 하는 경우가 발생한다. 초기 설계는 바로 완벽하게 나오긴 힘들기 때문에, 수정사항을 통해 코드가 수정, 추가, 제거 되는 과정에서 중복되는 또는 불필요한 코드가 남아 후에 재사용이 어려워지고 유지보수도 힘들게 된다.

TDD프로세스는 테스트를 먼저 작성하고 테스트를 통과하기 위한 최소한의 코드를 작성하는 것을 반복하여 그 사이에 생길 수 있는 문제를 또 테스트 케이스에 추가해 설계를 개선하고 최종적으로 테스트를 통과한 코드를 실제 개발단계에서 추가한다. 버그는 줄이고 코드는 간결하게 만들 수 있다.

TDD프로세스를 실천하는 방법으로는 UnitTest가 있다. Swift의 경우 XCode의 XCTest 프레임워크를 통해 테스트를 처리할 수 있다.

TDD의 장 단점

장점

• 유지보수에 용이하고, 배포단계의 에러나 버그를 현저히 줄일 수 있다.
• 추가적인 요구사항이 있어도 기존 프로세스보다 쉽게 반영이 가능하다.
• 테스트를 위해 개발하는 코드는 기능별로 모듈화가 잘 되어 완벽하게 객체지향적인 코드를 만들 수 있다.

단점

• 기존 개발방식에 비해 생산성이 떨어진다. 초기 설계부터 성공, 실패 케이스를 만들고 검증해나가며 수정을 하는데서 시간이 많이 소요된다.

TDD를 적용할 때

다른 프로젝트에서 여러번 코드를 작성해봤고 결과가 뻔하다면 TDD를 꼭 하지 않아도 된다. 불필요한 것 까지 하면 생산성을 더 낮추는 지름길이다.

TDD가 필요한 경우

1. 처음하는 프로그램 주제
2. 요구조건이 바뀔 수 있는 프로젝트
3. 개발 도중에 코드를 많이 바꿔야 된다고 생각하는 경우
4. 내가 개발하고 나서 이 코드를 누가 유지보수 할지 모르는 경우

대체로 외부-내부적인 불확실성이 높은 상황에서 TDD를 쓰는 것이 좋다.

개발 주기

TDD는 테스트를 만들고 검증하는것을 반복해 좋은 코드를 만들어간다 한 것 처럼 개발주기는 리팩토링->실패->성공의 주기를 갖고 있다.

• Red 단계에는 실패하는 테스트 코드를 먼저 작성.
• Green 단계에는 테스트 코드를 성공시키기 위한 코드 작성
• Refactor 단계에는 코드 중복제거 등의 리팩토링을 실시한다.

TDD는 애자일 실천법 중 하나로서 피드백과 협력을 동시에 증진시킨다.

---

TDD(Test-Driven-Development) 방법론 - CLIPSOFT

 

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