TDD 개념 정리

TDD 개발 원칙

• Clean code that works
• 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.
• 중복을 제거한다.
  
• 실패하는 테스트 코드를 한 번에 하나 이상 작성하지 않는다.

TDD 장점

ㆍ개발자의 방향을 잃지 않게 유지: 현재 자신의 개발 내용 및 진척 상황을 항상 살펴볼 수 있다.

ㆍ품질 높은 소프트웨어 모듈 보유 : 간결한 코드 유지 가능

ㆍ자동화된 단위 테스트 케이스 소유: 개발자가 필요한 시점에 언제든 수행할 수 있으며 시스템의 이상 유무를 바로 확인할 수 있다.

ㆍ사용설명서 & 의사 소통의 수단:  작성된 테스트 케이스는 제품 코드 사용 설명서이자 동시에 다른 개발자와 소통하는 커뮤니케이션 통로가 된다. (제품 코드 API 사용 예시가 된다.)

ㆍ설계 개선 : 테스트 케이스 작성 시 개발에 포함된 다양한 설계요소들에 대해 고민하게 된다. 흔히 테스트하기 어렵다고 생각되는 코드들은 객체 설계 원리 중 기본에 해당하는 원칙들이 잘못 적용됐거나 충분히 고려되지 않았을 가능성이 높다. TDD 진행하면서 테스트가 가능하도록 설계 구조를 고민하다 보면 자연스럽게 디자인을 개선하게 된다.

ㆍ보다 자주 성공한다 : TDD 는 주기를 짧게 설정하도록 권한다. 개발자는 성취감을 자주 느낄 수 있다.

[출처] Park's Park 블로그 : https://soulpark.wordpress.com/2012/09/12/test-driven-development/

TDD 한계

TDD 선구자인 Kent Beck 은 다음 두 가지를  TDD가 현재 접근하기 어려운 분야라고 말한다.

ㆍ동시성(Concurrency)

ㆍ보안 등의 비기능적 요소

이 외에 국내 TDD 도서 저자인 채수원씨는 본인의 도서에서 아래와 같이 추가적인 어려움들을 덧붙였다. 불가능하진 않지만 쉽지 않다는 의미로 받아들이면 될 것 같다.

ㆍ접근 제한자 메소드 : 현재는 public 메소드만 테스트해도 무방하다는 경향이 대세로 보이지만, 필요에 따라 public 으로 테스트 후 접근 제한자를 수정하는 방법도 있다.

ㆍGUI : 뷰 레이어와 로직 레이어를 확실히 분리시켜 설계할 필요가 있다.

ㆍ의존성 모듈 테스트 (target = A but A -> B) : 타겟 A 테스트를 위해 B 도 필요하다. 그러나  B가 아직 준비가 되어 있지 않다면 테스트가 이루어질 수 없다. 보통 이런 경우 B의 Mock객체를 생성하여 B는 문제없음을 가정하고 테스트 한다.

[출처] Park's Park 블로그 : https://soulpark.wordpress.com/2012/09/12/test-driven-development/

TDD 프로세스

• RED : 실패하는 테스트를 만든다. 이 때, 예상되지 않은 Exception은 실패가 아닌 오류로 기록된다. 테스트 케이스가 오류가 아닌 실패로 끝나도록 구현해야 한다.
• GREEN : 테스트를 통과할 만한 단위 코드를 작성한다. 
• REFACTOR : 코드를 효율적으로 리팩토링한다. 리팩토링 대상은 테스트 클래스와 제품 클래스 모두 해당한다.

위 과정을 거치며, 개발 과정에서 Test와 코드 리팩토링을 수행할 수 있다.

[참조]

Test-Driven Development

테스트 주도 개발방법론 TDD(Test-driven Development)이란?

[읽을거리]

TDD(Test Driven Development) 를 연습하면서 참고하기 좋은 팁 10가지