[TDD Chapter4] TDD 기능 명세 설계

⭐ 기능 명세 

파워포인트: 스토리 보드 형태
이메일: 간단한 형태
지라: 같은 이슈를 통해 추가할 기능의 명세
회의 자리: 구두로 전달

 

사용자에게 기능을 전달하기 위해서는 기능을 입력과 결과의 형태여야 한다. 

 

• 입력: 보통 메서드의 파라미터
• 결과: 여러 형식으로 정의
  • 리턴 값 등,, 
  • 변경 (회원 가입에서는 DB의 값을 추가하면서 시스템의 상태를 변경하는 것으로 리턴하는 것과 다름)

 

 

1. 스토리 보드를 포함한 다양한 형태의 요구사항 문서를 이용해서 기능 명세 구체화
2. 기능 명세를 구체화하는 동안 입력과 결과를 도출
3. 도출한 기능 명세를 코드에 반영 (기능의 이름, 파라미터, 리턴 타입 등이 결정)

 

 

⭐ 설계 과정을 지원하는 TDD

[과정]
1. 테스트 코드 생성
2. 코드를 구현하고 리팩토링 하는 과정

🔅 테스트 코드를 가장 먼저 작성 🔅

[설계 행위]
타입의 이름 정의 , 타입이 제공할 기능(필요한 값과 결과)을 결정하는 것

단, 1번을 하기 위해서는 테스트할 기능을 검색하고, 실행 결과 검증이 있어야 테스트 코드를 작성할 수 있는 것이다.

즉, 테스트에서 실행할 수 있는 객체나 함수가 존재해야 하는 것이다. 

 

 

 

🍀 필요한 만큼 설계하기

필요할 것으로 예측되는 코드까지 만드는 것이 아니라 테스트를 통과할 만큼만 코드를 작성한다.

이는, 설계에서도 동일하게 적용되어, 미리 설게하여 유연하게 만들지 않는다.

 

기능 실행 결과를 도출할 때, 미리 앞서서 필요해보이는 익셉션 타입을 생성하지 않는다. 

 

 

⭐ 기능 명세 구체화

테스트 코드를 작성하기 위해 개발자는 기능 명세를 정리해야 한다. 개발자는 기획자가 작성한 스토리 보드나 와이어프레임과 같은 형태로 요구 사항을 전달 받는다. 이러한 문서는 개발자가 구현하기에는 너무 생략된 내용이 많다.

 

또한 테스트를 추가하는 과정에서 구현하기 애매한 점을 발견하게 되면, 기획자나 실무 담당자와 이야기하여 상황에 따라 기능이 어떻게 동작해야하는지 구체적으로 정리를 해야한다.

 

 

테스트 코드는 바로 실행할 수 있고, 이는 유지보수를 하는데 큰 도움이 된다. 

 

복잡한 로직을 구현하는 것은 개발자이므로 개발자는 최대한 예외적인 상황이나 복잡한 상황에서 해당하는 구체적인 예를 끄집어내야 한다. 이를 위해 가장 좋은 방법은 담당자와 이야기를 나누는 것이다.