1️⃣ 지엔에서 프론트엔드 TDD(Test-Driven Development)를 도입한 이유
좋은 코드란 무엇일까요? 사람마다 기준은 다르겠지만, 의도가 명확하고 잘 모듈화된 코드는 누구나 공감할 수 있는 좋은 코드의 조건일 것입니다.
이러한 관점에서 TDD는 단순히 테스트 코드를 먼저 작성하는 것을 넘어, 개발자의 의도를 명확하게 전달하고 완성된 코드가 자연스럽게 모듈화 되는 결과를 낳는, 효과적인 방법론이라고 할 수 있습니다. TDD를 따라 개발하다 보면, 자연스레 테스트 코드를 충족하는 코드를 모듈 단위로 개발하게 되기 때문입니다.
2️⃣ TDD 실전 적용
더 나은 코드를 만들기 위해, 프론트엔드 팀에서는 TDD를 처음 도입하면서 어떤 부분부터 적용할지 고민하게 되었습니다.
그래서 가장 핵심적인 부분인 UI/UX부터 적용해보기로 결정했습니다. UI/UX 테스트에 TDD를 적용한 이유는 두 가지입니다.
첫째, 사용자 경험을 우선했습니다.
UI/UX는 사용자가 가장 먼저 마주하는 서비스의 "모습"입니다. 친절하지 않은 서비스는 불만족스러운 경험을 남기게 됩니다. TDD를 통해 UI의 안정성을 확보하고, 디자인 변경이나 피드백을 신속하게 반영할 수 있도록 만들었습니다.
둘째, 변경 사항을 빠르게 검증할 수 있습니다.
UI/UX는 자주 수정되기 때문에, TDD를 활용하면 코드 변경이 기존 기능에 미치는 영향을 신속하게 확인할 수 있습니다. 자동화된 체크리스트처럼, 변경 사항을 빠르게 검증할 수 있습니다.
추가로, UI/UX 테스트를 위해 Controller-Presenter 개발 패턴을 선택했습니다.
Controller는 비동기 데이터를 가져오거나 비즈니스 로직을 처리하는 역할을 합니다.
Presenter는 사용자에게 보여지는 UI와 관련된 로직을 담당합니다.
이 패턴을 사용하면 UI와 비즈니스 로직을 명확하게 분리할 수 있어, 각 컴포넌트를 독립적으로 테스트할 수 있습니다. 덕분에 테스트의 범위와 효율성이 높아지며, 우리는 UI/UX 테스트에 집중하기 위해 Presenter만 안전하게 테스트할 수 있습니다.
3️⃣ TDD 방식의 구체화
DD는 Red - Green - Refactor라는 간단한 사이클을 따릅니다.
Red: 실패하는 테스트를 먼저 작성합니다.
Green: 테스트를 통과할 최소한의 코드를 작성합니다.
Refactor: 중복을 제거하고 코드를 개선합니다.
그렇다면, 실제로 이 사이클로 TDD 방식을 어떻게 적용했는지 구체적으로 살펴보겠습니다.
3.1. Red: 실패하는 테스트 코드 작성
TDD 초기에는 UI 기획서를 기반으로 앱에서 필요한 기능과 컴포넌트를 정의한 후, 이를 테스트 코드로 먼저 작성했습니다.
예를 들어,
버튼 클릭 시 상태가 변경되는지
리스트 아이템 클릭 시 다른 화면으로 전환되는지
와 같은 사용자 상호작용을 테스트 코드로 정의했습니다.
이 단계에서는 실제 기능을 구현하지 않기 때문에 모든 테스트가 실패하게 됩니다.
여기서 중요한 점은 UI 기획서를 단순히 참고하는 것이 아니라, 그 안에 담긴 기능적 요구사항을 테스트 코드로 구체화했다는 것입니다. 즉 테스트 코드가 기능 정의서 역할을 하게 된 것이죠.
3.2. Green: 테스트를 통과하는 최소한의 코드 작성
테스트 코드를 작성한 후, 이를 통과할 수 있도록 코드를 구현했습니다.
이 단계에서 중요한 점은 테스트가 실패하는 상황에서 시작하여, 그 실패를 해결하는 방향으로 코드를 작성한다는 것입니다.
실제 코드 작성 시에는 기능 구현에 집중하기보다는 테스트를 통과하는 데 초점을 맞추어, 가장 간단한 형태로 구현을 시작했습니다.
이 과정을 통해 최소한의 코드로 기능을 완성하고, 테스트를 통해 기능이 올바르게 동작하는지 검증할 수 있었습니다.
결과적으로 불필요한 코드나 복잡한 로직을 줄이고, 필요한 기능을 정확하게 구현하는 데 유리한 방식이 되었습니다.
3.3. Refactor: 코드 리펙토링
기능이 정상적으로 동작하면, 코드를 리팩토링하여 가독성과 유지보수성을 개선했습니다.
이 과정에서 단순히 코드 스타일을 다듬는 것이 아니라, 가독성과 유지보수성을 높이는 데 집중했습니다.
예를 들어,
컴포넌트를 모듈화하고
기능을 함수로 분리하는 등
코드를 더 직관적이고 확장 가능하게 만들었습니다.
또한, 리팩토링 단계에서는 기존 코드가 정상적으로 동작하는지 확인하는 것이 중요했습니다.
이를 위해 리팩토링 후에도 기존 테스트가 정상적으로 통과하는지 지속적으로 검증하며 작업을 진행했고, 그 결과 코드의 안정성을 보장할 수 있었습니다.
4️⃣ 기대효과와 앞으로의 과제
TDD를 적용한 지 얼마 되지 않아 좀 더 다듬고 싶은 부분도 많았지만, 이전보다 의도대로의 모듈화된 코드가 나오게 된 것 같았습니다.
앞으로는 테스트 코드의 품질을 위해 다양한 케이스를 확보해 나가는 것이 중요할 것 같습니다. 프로젝트를 발전시키며 테스트 코드도 함께 유지보수해 나가면, 그 자체로 훌륭한 가이드가 되어줄 것이라고 믿습니다. 이 가이드가 후속 팀원들이 쉽게 따라올 수 있도록 도와주는 이정표 역할을 할 수 있기를 바라며 글을 마무리 하겠습니다. ☺️
<출처>