기능 명세
사용자에게 제공할 기능을 구현하려면 기능을 크게 두 가지로 나누어 생각할 수 있다.
- 입력
- 결과
예를 들면, 로그인 기능에서는
- 입력: 아이디와 암호
- 결과: 아이디와 암호가 일치하면 성공, 일치하지 않으면 실패
또다른 예시로 만료일 계산 기능에서는
- 입력: 첫 납부일, 납부일, 납부액
- 결과: 만료일
이 된다.
입력은 보통 메서드의 파라미터로 전달한다.
결과는 여러 형식으로 정의될 수 있고, 그 중 대표적인 예시가 리턴 값이다.
익셉션도 결과로 사용할 수 있다. (ex. 로그인 인증 실패시 IdPwNotMatchException)
기능 실행 결과에는 변경도 포함된다. (ex. DB에 데이터 추가는 시스템 상태 변경이 결과이다.)
설계는 기능 명세로부터 시작한다.
기능 명세의 입력과 결과를 코드에 반영하는 과정에서 기능의 이름, 파라미터, 리턴 타입 등이 결정된다.
이는 곧 기능에 대한 설계 과정과 연결된다.
설계 과정을 지원하는 TDD
TDD는 테스트를 만드는 것으로 부터 시작한다.
테스트 코드를 만들기 위해서 필요한 것 두가지는
- 테스트할 기능 실행
- 실행 결과를 검증
이다.
다음은 테스트코드를 작성하는 과정에서 결정해야 하는 것들이다.
- 클래스 이름
- 메서드 이름
- 메서드 파라미터
- 실행 결과
TDD에서 테스트코드를 작성할 때 고민하는 것과 설계 과정에서 고민하는 것은 유사하다.
TDD 자체가 설계는 아니지만, 테스트코드를 작성하는 과정에서 일부 설계를 진행하게 된다.
필요한 만큼 설계하기
필요할 것으로 예측해서 미리 설계를 유연하게 만들지 않고, 필요한 만큼 설계를 변경한다.
실제 익셉션이 필요한 시점에 익셉션을 도출한다.
현시점에서 테스트를 통과시키는데 필요한 만큼의 코드만 만들고, 유연한 설계는 필요한 시점에 추가한다.
기능 명세 구체화
테스트 코드를 작성하기 위해 개발자는 기능 명세를 정리해야 한다.
요구사항 문서에서 기능의 입력과 결과를 도출해야 한다.
또한, 테스트 사례를 추가하는 과정에서 구현하기 애매한 점을 발견하고 이를 구체적으로 정리해야 한다.
테스트코드는 구체적인 입력과 결과를 이용해서 작성하므로 개발자는 예를 통해 기능 명세를구체화 하게 된다.
개발자는 최대한 예외적인 상황이나 복잡한 상황에 해당하는 구체적인 예를 끄집어내야 한다.
