TDD.md

TDD(Test-Driven Development)

목표

• 테스트가 개발을 이끌어나간다
• 잘 동작하는 깔끔한 코드를 생산하자(clean + work)
• 코드 품질을 높이고, 유지보수에 이득을 취하자

그라운드룰

1. 실패하는 테스트를 작성하기 전에는 절대로 제품 코드를 작성하지 않는다.
2. 실패하는 테스트 코드를 한 번에 하나 이상 작성하지 않는다.
3. 현재 실패하고 있는 테스트를 통과하기에 충분한 정조를 넘어서는 제품 코드를 작성하지 않는다.

장단점

장점

• 품질 보장 : Test를 먼저 거치기 때문에 버그에 낭비하는 시간 감소
• 설계 개선 : Test코드 작성시 다양한 케이스, 변수명, 메소드 등에 이르는 개발에 포함한 다양한 요소들에 대해 미리 고민
• 개발 방향성 유지 : 구현한 기능이 요구사항에 충족하는지 쉽게 확인 가능

단점

• 빠른 개발환경에서는 도입이 어려움
• TDD에 대한 학습 필요
• 생산성 저하

특징

• 설계는 Top-Down, 구현은 Bottom-Up
• 적응할 수 있는 객체지향적인 코드를 개발
• 어차피 발견될 결함이라면, 최대한 일찍 발견해야한다
• 처음엔 바보 같은 코드를 짜라
• 테스트 시나리오를 구상하자
• 유닛테스트가 곧 문서다

 TDD를 한다는 것은 단순히 테스트 코드를 먼저 작성하는 것이 아니라 
 Refactoring을 통해 Clean Code를 유지하려고 노력하는 것 
 Simple Design으로 시작해서 점진적으로 설계 개발하겠다는 것 
 작은 기능이라도 사용자에게 가치있는 제품을 전달하겠다는 것

 소프트웨어의 모든 것은 변한다. 요구사항은 변한다. 설계도 변한다. 비지니스도 변한다. 기술도 변한다. 팀도 변한다. 팀 구성원도 변한다. 변화는 반드시 일어나기 때문에, 문제가 되는 것은 변화가 아니다. 그보다는 변화를 극복하지 못하는 우리의 무능력이 문제다.
    -익스트림 프로그래밍-

Refactoring!!
'결과의 변경 없이 코드의 구조를 재조정함'을 뜻한다. 
주로 가독성을 높이고 유지보수를 편하게 한다.
버그를 없애거나 새로운 기능을 추가하는 행위는 아니다.
사용자가 보는 외부 화면은 그대로 두면서 내부 논리나 구조를 바꾸고 개선하는 유지보수 행위이다.

활용이 어려운 이유

1. 개발 시간이 증가한다
2. 개발 방식을 바꿔야한다
3. 도구/규칙에 집착한다

통합테스트 vs 유닛 테스트