TDD (Test Driven Development)

◎ TDD (Test Driven Development)

• ‘테스트를 먼저 하고 구현은 그 다음에 한다’
• 테스트를 우선적으로 만들고, 그 테스트가 통과 할만큼의 실제 기능을 구현함

◎ 전통적인 개발 방식

• 개발 방식 순서

  1. 서비스 제작에 관여하는 사람들이 모여 서버스에 대한 컨셉과 해당 컨셉에 따른 요구사항을 지속적으로 수집

  2. 수집된 요구사항에 맞추어 UI(User Interface)를 설계하면서 구체적인 기능의 요구 사항들을 정의

  3. 프런트엔드 개발자는 기능 요구 사항과 UI를 통해 개발을 진행하고, 웹 디자이너는 화면을 디자인하며, 백엔드 개발자는 기능 요구 사항에 맞추어 어플리케이션을 디자인함

     3-1. 백엔드 개발자는 설계된 UI를 기반으로 도메인 모델을 도출함
     3-2. 도출된 도메인 모델을 통해 엔드포인트, 비즈니스 로직, 데이터 엑세스 계층 등 큰그림을 설계한 후, 작성함
     3-3. 큰 틀이 작성된 후, 세부 메서드를 정의하면서 세부 동작을 구현
     3-4. 기능 구현 후, 기능이 잘 동작하는지 테스트함
     3-5. 테스트에 문제가 발생한다면, 구현한 코드를 디버깅하면서 문제의 원인을 찾음

• 전통적인 개발 방식의 특징

  • 선 구현 후 테스트 방식

◎ TDD의 특징

• TDD 개발 방식 (해당 과정을 반복)
  : 실패하는 테스트
  → 실패하는 테스트를 성공할 만큼의 기능 구현
  → 성공하는 테스트
  → 리팩토링
  → 실패하는 테스트와 성공하는 테스트 확인

• TDD의 특징

  • 한번에 너무 많은 기능을 구현할 필요가 없다.
  • 테스트의 코드가 추가되면서 검증하는 범위가 넓어질 수록 기능 구현도 점진적으로 완성함
  • 그때그때 리팩토링을 진행하기 때문에 리팩토링의 비용이 상대적으로 적다.
  • 리팩토링을 통해 꾸준히 코드를 개선하므로 코드의 품질을 일정 부분 유지할 수 있다.
  • 코드 수정 이후, 바로 테스트가 가능하므로 빠른 피드백이 가능하다.

• TDD의 단점

  • 기존 개발자들이 TDD 방식이 익숙치 않음
  • 팀 단위로 개발을 진행해야 하므로 팀원들 간 사전 협의가 되어야 한다.