패스트캠퍼스 이규원의 현실 세상의 TDD 강의 후기와 이후 TDD에 대한 생각

테스트 코드 작성과 TDD에 대해서 콘퍼런스 세션을 듣거나 다른 사람의 글을 읽은 적은 있지만, TDD는 커녕 테스트 코드 작성 경험도 없다시피했다. 많은 상태와 UI를 다루고, 빠르게 기획이 변경되는 프런트엔드에서 쉽지 않을 것이라 생각하기도 했다. 그런데 이번에 새로 합류한 팀은 UseCase 단위로 테스트 코드를 작성하여 도메인 논리를 검증하는 것을 적극 사용하고 있어 빠르게 관련된 지식을 탑재하는 게 필요했다. 개발 리드분으로부터 패스트캠퍼스의 ‘이규원의 현실 세상의 TDD’ 강의를 추천받았고, 이 글은 그 강의를 듣고 작성하는 후기이다.

감사하게도 회사의 지원으로 강의를 수강할 수 있었다. 구성원의 성장에도 진심인

!

강의는 총 두 편이 있는데, 첫 강의명이 이론편이라고 되어있지는 않지만 편의상 이론편과 실전편이라고 지칭하겠다. 이론편은 약 11시간, 실전편은 약 13시간 정도의 러닝타임으로 구성되어 있다. 나에게는 생각보다 말의 속도가 느리게 느껴져서 1.2배속으로 시청했고, 별 부담없이 들을 수 있었다. 중간중간 코딩 시간이나 비슷한 작업을 할 때에는 조금씩 앞으로 넘기면서 시청하여 러닝타임보다는 적게 시간을 사용했다.

이론편에서는 테스트 기법과 TDD에 대한 설명, 테스트 더블과 Mockists와 Classicists, 테스트를 기반으로 한 개발 방식에 대한 내용 등을 다루고 있다. 실전편에서는 주문 및 정산 기능 개선과 B2B 계정관리 기능 개선이라는 작업을 통해 TDD를 어떻게 적용하는지 직접 개발하며 생각의 흐름을 알려주는 방식으로 진행되었다.

이론과 개념에 대한 정의부터 부족했던 나에게 이론편은 많은 도움이 되었다. 강의를 듣고 난 후 이전에 작성한 테스트 코드를 리팩터링했는데, 처음보다 한결 그림이 그려지는 느낌이었다. 실전편은 실제 코드를 개선하는 과정에서 생각의 흐름을 들을 수 있는 것은 좋았으나, 강의의 절반 정도는 남겨두었다. 이후에는 강의가 아닌 실제 테스트 코드를 작성하는 과정에서 훈련하고, 다른 테스트 관련 책을 읽는 방식으로 더 학습할 예정이다. TDD에 대한 길을 찾고 있는 단계라면, 꽤 도움이 많이 될 수 있는 강의라고 생각한다.

강의 내용에도 나오는 것처럼 인간 친화적 소통 수단인 UI 단계에서는 테스트 자동화 비용이 높기 때문에 효과적이라고 생각되지는 않는다. 하지만 내부 논리일수록 그것이 특히 복잡한 도메인 논리일수록 테스트 자동화는 소프트웨어 회귀를 방지하거나 개발자가 안심하고 작업할 수 있는 환경을 만들어 줄 수 있다는 것에는 공감한다.

TDD에 대해 멘탈 모델이 바뀌기도 했다. 개발 과정에서 결과물을 보고 다시 코드를 수정하거나, 버그를 재현하며 원인을 분석하고 수정해가는 과정과 본질적으로 다르지 않게 느껴진다. 테스트 코드는 초기 구축 비용만 들이면 자동화를 통해 이 과정에서 들어가는 인력을 대체하여 안정적으로 프로그래머에게 피드백을 전달해준다.

테스트 코드를 먼저 작성하여 실패를 확인하는 RED, 최소한의 코딩으로 테스트 통과를 확인하는 GREEN, 구현 및 설계를 리팩터링하며 테스트 통과를 유지하는 BLUE의 사이클로 이어지는 그림은 TDD를 이해하는 데 많은 도움이 되었다.

빨리 시도해보고 싶은 마음으로 개발해야할 것을 명확히 하지 않은 채 개발을 시작하면, 중간에 머리를 부여잡는 시간이 오는 경우가 꽤 있다. TDD는 테스트 코드를 작성하는 단계에서 목표를 명확히하는 것을 요구하여 이후 있을 고민 시간을 효과적으로 줄여줄 수 있다. 아무렴 초기의 변경이 더 쉬우니 말이다.

인터페이스를 어떻게 설계할 지, 어떤 단위로 테스트를 진행할 지, 테스트 더블을 어떻게 사용할 지, Mockists인지 Classicists인지, 논리에 어떤 테스트 코드들이 있어야 거짓 음성이나 거짓 양성을 없앨 수 있을 지 등… 실제 활용 수준으로 들어가면 여전히 고민되고 어려운 부분은 많다.

각 프로젝트 상황에서 TDD 도입에 대해 어떤 트레이드오프가 있는지 따져보는 것은 여전히 매우 중요하다.