TDD(테스트 주도 개발)

안녕하세요 멋사3기 Kyunni입니다.

이번 포스팅은 강의의 내용과는 별개로 테스트 주도 개발에 대해 포스팅 해볼까 합니다. 이두희 대장님이 정말 한 단어 스치고 가신 바로 그 '테스트 주도 개발 (TDD)'을 캐치해서 공부해보기로 했습니다. :)

TDD(테스트 주도 개발)의 정의

린(Lean) 소프트웨어 개발론의 핵심 철학 중 하나는 "결함은 발견 즉시 해결"입니다. 린 개발은 이것의 실천법으로 테스트 주도 개발(Test-Driven Development, TDD)를 제시하였습니다.

TDD는 반복 테스트를 이용한 소프트웨어 개발법입니다. 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 소프트웨어를 구현합니다.

TDD의 목표

TDD의 궁극적인 목표는 작동하는 깔끔한 코드 입니다.

"Clean code that works"

TDD는 테스트 케이스를 생성합니다. 테스트 케이스는 자동화된 테스트 도구로서 이용되어, 코드 변경시 기존 기능이 제대로 동작하는 지 쉽게 확인할 수 있고, 정상 작동을 보장합니다. 또한 Refactoring을 개발 프로세스에 포함시켜 '변경'이라는 소프트웨어의 특성을 반영합니다.

이를 위한 두 가지 원칙은 아래의 내용입니다.

1. 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.

2. 중복을 제거한다.

3. 실패하는 테스트를 작성하기 전에는 절대로 제품 코드를 작성하지 않는다.

4. 실패하는 테스트 코드를 한 번에 하나 이상 작성하지 않는다.

5. 현재 실패하고 있는 테스트를 통과하기에 충분한 정도를 넘어서는 제품 코드를 작성하지 않는다.

TDD의 개발법

• RED
  실패하는 작은 테스트 케이스를 작성합니다. 처음에는 컴파일 조차 안될 수도 있습니다.

• GREEN
  테스트를 통과하는 코드를 작성합니다.

• REFACTOR
  테스트를 통과하기 위해 만든 코드의 모든 중복을 제거하고, 불명확한 것을 명확히 합니다.

TDD의 장점

1. 개발자의 방향을 잃지 않게 유지시켜줍니다.

2. 품질 높은 소프트웨어 모듈을 보유합니다.

3. 자동화된 단위 테스트 케이스를 소유합니다.

4. 사용설명서 & 의사소통의 수단이 됩니다.

5. 설계 개선

6. 상대적으로 자주 성공합니다. 

TDD의 한계

1. 동시성 (Concurrency)

2. 보안 등의 비기능적 요소

3. 접근 제한자 메소드

4. GUI

5. 의존성 모듈 테스트