sosa0sa.com

원문 : Assessing Test Driven Development at IBM

IBM에서 JavaPOS 과제에 대해 TDD를 적용한 사례 정리

기존 과제에서의 Unit Testing

• 대부분의 경우 Unit testing은 개발이 이루어진 후에 일어남.
• 일정이 빠듯한 경우 생략됨

JavaPOS 과제에서는

• 생소한 방법론이나 생산성에 대한 우려를 해소하기 위해 일정 수립에 심여를 기울임.
• 개발자와 매니저의 반발
• 기존 과제를 분석하여 400 LOC/MM 를 목표로 설정함
• 생산성 factor
  • Defect rate - defect rate in short term and long term
  • roductivity - LOC/MM
  • Test Frequency - ration of interactive vs. automated test? how often?
  • Design - more robust design?
  • integration - smoother code integration?
• XP에서는 전체 디자인을 하지 않고 코딩을 하지만, JavaPOS의 경우 요구사항이 비교적 유동적이지 않아 UML을 이용하여

Big Design Up Front를 수행함.

• 중요 클래스에 대해 unit test를 강제화함.
• 중요 클래스에 대해 80%의 자동화된 unit test를 목표로 함.
• Build & Unit testing in Daily
• Unit test는 정상 경우, 예외처리(특히 boundary value)를 포함

결과

• FVT(Functional Verification Test) 기준 기존 대비 50%의 defect rate를 보임.

• TDD(w/ Unit testing)은 개발 초기에 도입해야 함

• 핵심 항목에 대해서는 Unit Test 강제화도 고려할 필요가 있음