기능 명세
개발자가 코드를 작성하는 이유는 사용자가 사용할 어떤 기능을 제공하기 위함이다. 기능에 대한 명세는 다양한 형태로 존재한다. 파워포인트를 이용한 스토리 보드 형태일 수도 있고 회의 자리에서 간단하게 구두로 전달받을 때도 있다.
어떤 형태가 되든 간에 사용자에게 제공할 기능을 구현하려면 기능을 크게 두 가지로 나누어 생각해야 한다. 바로 입력과 출력이다. 예를 들어 회원가입 기능에서 입력과 결과는 다음과 같이 정의할 수 있다.
- 입력: 회원가입 정보
- 출력: 중복되는 아이디가 없다면 성공, 중복되면 실패
설계는 기능 명세로부터 시작한다. 다양한 형태의 요구사항 문서를 이용해서 기능 명세를 구체화한다. 구체화 과정은 다음과 같다.
- 입력과 결과를 도출한다.
- 도출한 기능 명세를 코드에 반영한다.
이런 과정에서 기능의 이름, 파라미터, 리턴 타입 등이 결정된다. 이는 곧 기능에 대한 설계 과정과 연결된다.
설계 과정
TDD는 테스트를 만드는 것에서 시작한다. 테스트 코드를 먼저 만들고 통과시키기 위한 코드를 구현하고 리팩토링하는 과정을 반복한다. 여기서 중요한 점은 테스트 코드를 먼저 만들어야 한다는 것이다. 테스트 코드를 먼저 만들기 위해 필요한 것은 다음과 같다.
- 테스트할 기능을 실행
- 실행 결과를 검증
이런 과정에서 클래스 이름, 메서드 이름, 파라미터, 리턴 타입 등을 고민하게 될 것이다. TDD에서 테스트 코드를 작성할 때와 설계 과정에서 고민하는 것은 겹치는 부분이 있는 것을 알 수 있다. 즉 TDD 자체가 설계는 아니지만, TDD를 하다 보면 테스트 코드를 작성하는 과정에서 일부 설계를 진행하게 된다.
필요한 만큼 설계하기
TDD는 테스트를 통과할 만큼만 코드를 작성하면서 점진적으로 구현하는 것이 핵심이다. 필요할 것으로 예측해서 미리 코드를 한 번에 구현하지 않는다. 개발하면서 요구사항이 종종 변하는데, TDD는 미리 앞서서 코드를 만들지 않으므로 불필요한 구성 요소를 덜 만들게 된다.
기능 명세 구체화
보통 개발자는 기획자가 작성한 스토리보드나 와이어프레임과 같은 형태로 요구사항 명세를 전달받는다. 이런 문서는 개발자가 기능을 구현하기에는 모호성이 많다. 테스트 코드를 작성하려면 입력과 출력이 명확해야 하므로 애매한 점이 발견될 것이다.
가장 좋은 방법은 담당자와 대화를 하는 것이다. 최대한 얘기를 나누면서 모호성을 없애고 예외적인 상황이나 복잡한 상황에 해당하는 구체적인 예를 끄집어내야 한다. 대화 과정이 쉽지 않을 때도 있지만 대화를 하지 않으면 올바르게 원하는 결과물을 개발하지 못한다.
'TDD' 카테고리의 다른 글
| [테스트 코드의 구성] (0) | 2023.02.04 |
|---|---|
| [JUnit 5 기초] (0) | 2023.02.04 |
| [TDD 테스트 코드 작성 순서] (0) | 2023.01.15 |