[TDD] 기능 명세 ∙ 설계

기능 명세

개발자는 코드를 작성하고 빌드하여 이를 사용자가 사용할 수 있게 배포한다. 설계는 기능 명세로부터 시작한다. 스토리보드를 포함한 다양한 형태의 요구사항 문서를 이용해서 기능 명세를 구체화한다. 기능 명세를 구체화하는 동안 입력과 결과를 도출하고 이렇게 도출한 기능 명세를 코드에 반영한다. 기능 명세의 입력과 결과를 코드에 반영하는 과정에서 기능의 이름, 파라미터, 리턴 타입 등이 결정된다.

설계 과정을 지원하는 TDD

TDD에서 가장 중요한 것을 테스트 코드를 먼저 작성한다는 점이다. 리턴 타입과 파라미터 타입에 대해서 고민은 곧 설계 과정이다. 타입의 이름을 정의하고 타입이 제공할 기능을 결정하는 것은 기본 적인 설계 행위이다. TDD 자체가 설계는 아니지만, TDD를 하다 보면 테스트 코드를 작성하는 과정에서 일부 설계를 진행하게 된다.

이름

이름은 설계에서 매우 중요하다. 설계 과정에서 구현하는 기능을 정확하게 표현하는 이름을 사용한 것 만큼 중요한 것은 없다. 잘못 지은 이름은 두고두고 개발자를 속인다. 테스트 코드는 시작부터 이름을 고민하게 만든다. 이 순간은 그래서 중요하다. 시간이 다소 걸리더라도 알맞은 이름을 찾아야 한다. 이름을 고민하는 시간을 아까워하지 말자.

필요한 만큼 설계하기

TDD는 테스트를 통과할 만큼만 코드를 작성한다. 필요한 것으로 예측해서 미리 코드를 만들지 않는다. 유연한 설계는 필요한 시점에 추가하고 설계가 불필요해지는 것을 방지한다.

기능 명세 구체화

모호한 상황을 만나면 이를 구체적인 예로 바꾸어 테스트 코드에 반영한다. 즉 테스트 코드는 예를 이용한 구체적인 명세가 된다. 구체적인 예는 개발자가 요구사항을 더 잘 이해할 수 있도록 만든다. 복잡한 로직을 구현하는 것은 결국 개발자 이므로 개발자는 최대한 예외적인 상황이나 복잡한 상황에 해당하는 구체적인 예를 끄집어내야 한다. 이를 위한 가장 좋은 방법은 담당자와 대화를 하는 것이다.

 

 

4주차 - TDD ∙ 기능 명세 ∙ 설계 - 한규범 · Issue #40 · GDSC-MYONGJI/22-23-TDD-Study

 

Reference.

테스트 주도 개발 시작하기 - YES24