4장 TDD, 기능 명세, 설계

기능 명세

• 결과는 여러 형식으로 정의할 수 있다. 가장 쉽게 생각할 수 있는 결과 형식은 리턴 값이다.
• 익셉션을 결과로 사용할 수도 있다.
• 기능 실행 결과에는 변경도 포함한다.
• 이런 변경은 리턴 값으로는 결과를 알 수 없기 때문에 테스트 대상을 실행한 뒤에는 변경 대상에 접근해서 결과를 확인해야 한다.
• 설계는 기능 명세로부터 시작한다.
• 기능 명세의 입력과 결과를 코드에 반영하는 과정에서 기능의 이름, 파라미터, 리턴 타입 등이 결정된다.

설계 과정을 지원하는 TDD

• 테스트 코드를 가장 먼저 작성해야 한다는 점이다.
• 테스트를 작성하기 위해 가장 먼저 고민한 것은 테스트 대상이 될 클래스의 이름이었다.
• 테스트 대상이 되는 타입의 이름을 결정한 뒤에는 테스트 코드에서 호출할 메서드를 고민했다.
• 이를 위해 실행 결과를 어떻게 검증할 수 있는지 고민해야 한다.
• 테스트 코드를 작성하는 과정에서 다음의 네 가지를 결정했다.
  • 클래스 이름
  • 메서드 이름
  • 메서드 파라미터
  • 실행 결과
• 이 네가지를 결정하는 과정에서 이름을 고민하고 파라미터 타입과 리턴 타입을 고민했다. 이는 곧 설계 과정이다.
• 이름은 설계에서 매우 중요하다. 설계 과정에서 구현하는 기능을 정확하게 표현하는 이름을 사용하는 것만큼 중요한 것은 없다.

필요한 만큼 설계하기

• TDD는 테스트를 통과할 만큼만 코드를 작성한다. 필요할 것으로 예측해서 미리 코드를 만들지 않는다. 이는 설계에도 동일하게 적용된다.
• 기능 실행 결과도 동일하다. 미리 앞서서 필요해 보이는 익센셥 타입을 만들지 않는다.
• 유연한 설계는 필요한 시점에 추가한다.

기능 명세 구체화

• 개발자는 요구사항 문서에서 기능의 입력과 겨로가를 도출해야 한다.
• 즉 테스트 코드는 예를 이용한 구체적인 명세가 된다. 
• 구체적인 예를 이용해서 테스트 코드를 추가하다 보면 기능 명세를 보다 잘 이해하고 모호함을 없앨 수 있다.
• 대화과정이 쉽지 않을 때도 있지만 대화를 하지 않으면 올바르게 원하는 결과물을 개발하지 못한다.