TDD 란 무엇이며 어떠한 장점이 있는가

TDD

Test Driven Development. 테스트 주도 개발

• 작은 단위의 테스트 케이스를 작성하고, 이를 통과하는 코드를 추가하는 단계를 반복하여 구현.

• 짧은 개발 주기의 반복에 의존.
  

• Red: 실패하는 테스트 코드 먼저 작성

• Green: 테스트 코드를 성공시키기 위한 실제 코드 작성

• Blue: 중복 코드 제거, 일반화 등 리팩토링

• 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않기.

• 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성.

• 실제 코드에 기대하는 바를 명확히 정의.

• 불필요한 설계 피하고, 정확한 요구 사항에 집중.

일반 개발 방식 vs TDD 개발 방식

일반 개발 방식

• 요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포
• 초기 설계가 완벽하지 않을 수 있음. 점진적으로 재설계하는 과정에서 불필요한 코드가 남거나 중복처리 될 가능성이 큼.
• 작은 부분 기능 수정에도 모든 부분 테스트 해야하므로 전체적 버그 검출 힘듦.
• 재사용이 어렵고, 관리가 어려워져 유지 보수가 어려워짐.

TDD 개발 방식

• 테스트 코드를 작성한 뒤에 실제 코드 작성.
• 설계 단계에서 프로그래밍 목적을 미리 정의, 무엇을 테스트할지 테스트 케이스 미리 작성.
• 테스트 코드 작성 중 발생하는 예외 사항을 테스트 케이스에 추가하고 설계 개선.
• 이후 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성.

효과

• 디버깅 시간 단축.
• 코드가 내 손을 벗어나기 전에 가장 빠르게 피드백 받을 수 있음.
  • 기능 단위로 테스트 하므로, 원인을 진단하기 수월함.
• 작성한 코드가 가지는 불안정성을 개선하여 생산성 향상.
  • 문제가 없는지 먼저 진단.
• 재설계 시간 단축
  • 사전에 개발 목표 정의.
  • 테스트 시나리오 작성하며 다양한 예외 사항 생각함.
• 추가 구현 용이
  • 개발이 완료된 소프트웨어에 기능 추가할 때, 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 모른다는 점.
  • TDD의 경우, 자동화 된 유닛 테스팅을 전제하므로 테스트 기간 단축.

단점

• 생산성 저하
  • 테스트 코드와 실제 코드 2개의 코드를 짜야하고, 테스트하며 고쳐야하므로 일반 개발 방식보다 10~30% 늘어남.
• 기존 개발 방식 바꿔야 함.
• 구조에 얽매임
  • 실제 코드가 테스트보다 중요한데, 테스트 원칙을 우선시 하게 됨.

레퍼런스

https://inpa.tistory.com/entry/QA-%F0%9F%93%9A-TDD-%EB%B0%A9%EB%B2%95%EB%A1%A0-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%A3%BC%EB%8F%84-%EA%B0%9C%EB%B0%9C