TDD에 대해 흔히 오해하는 점은 구현 코드를 작성하기 전에 테스트를 먼저 작성해야 한다는 것입니다. 제가 구글에서 검색한 상위 5개 문서에서도 첫 단계를 다음과 같이 소개합니다.
- 실패하는 작은 단위 테스트를 작성한다
- 테스트를 작성한다 (빨간막대)
- 만들고 싶은 기능을 점검할 테스트 코드를 작성한다
하지만 TDD를 연습하다 보면 숨겨진 과정을 발견하게 됩니다. 바로 어떤 변경을 기대하는지 목록을 만드는 것입니다. 이 목록은 테스트를 만들기 전에 먼저 작성해야 하고, 테스트/구현/리팩터링 사이클 과정에서 새로 알게 된 지식에 따라 추가되거나 합쳐질 수 있습니다. 이러한 목록 작성은 비단 TDD뿐만 아니라 다른 영역에서도 활용됩니다. 추정을 위한 작업 목록, 테크 스펙, 할일 목록 등으로 나타납니다.
1. 만들어 봐야 안다 (어떻게 동작할지 구현하기 전에 어떻게 아나)
우리는 기존 문서를 검토하여 비즈니스 규칙을 파악하고, 시스템이 어떻게 동작할지 가정합니다. 또한, 기존 코드를 분석하여 순서와 의존성을 이해하고, 새로운 요구사항이 기존 시스템에 어떻게 적합한지 판단합니다. 이러한 사전 분석과 계획을 통해 어떤 순서로 어떻게 구현할지 목록을 만들 수 있습니다. 학습 브랜치나 프로토타이핑을 통해 동작을 더 자세히 파악할수도 있습니다. 다만 이때 만들어진 코드는 파악을 위한 용도로 끝나야 하며 최종 결과물이 되면 안됩니다.
2. 변할 수 있다 (기획이 바뀌거나 생각지 못한 이슈가 발생하거나)
변화는 개발 과정에서 불가피하며, 사전에 작성된 목록은 변화에 끌려가는 것이 아니라 이끄는 것을 가능하게 해줍니다. 목록을 통해 예상되는 변경 사항과 그 영향 범위를 미리 파악하면, 초기에 예외나 변경을 통제할 수 있는 기회를 갖게 되며, 기획 변경이나 예상치 못한 이슈가 발생하더라도 능동적으로 대응할 수 있습니다.
3. 필요할 때 만들면 되지 (애자일하지 않아. 미리 만드는 건/설계하는 건 폭포수 모델이야)
미리 목록을 만드는 것을 모든 것을 미리 설계하고 그 설계대로만 만드는 폭포수 모델로 생각할 수 있지만, 이런 경직된 접근과는 다릅니다. 개발 과정에서 이 목록을 유동적으로 관리하고, 새로 알게 된 지식에 따라 추가하거나 수정합니다. 이러한 접근은 애자일한 방법론과 일치하며, 목표를 가시성 있게 관리하고 협업을 원활하게 진행할 수 있게 해줍니다.
개발자들의 가장 큰 무기 중 하나는 분할 정복입니다. 목록은 복잡한 문제를 여러 단순한 문제로 분할한 결과물이 되고, 각 항목은 쉽게 해결할 수 있는 정복의 대상이 됩니다. 분할정복하지않고 한번에 하면 안됩니다. Tidy First 에서 구조변경과 동작변경을 나누라는 말과도 비슷합니다. 우리의 뇌는 적절한 크기의 문제를 해결하는 데 최적화되어 있으며 개별 목록을 만들고 각 목록을 해결하면서 생산성을 높일 수 있습니다. 개발자는 이 분야에서 가장 숙달된 전문가 입니다.
참고