007_TDD, 그리고 Storybook

@TDD

TDD?

 개발자라면 한번쯤 TDD라는 단어에 대해 들어봤을 것이다. TDD란 테스트 주도 개발(Test Driven Development)의 약자를 뜻하며 기존의 개발 방식과는 조금 다른데, 그 방식의 차이는 다음과 같다.

 

 기존에는 설계 이후 개발 및 테스트케이스를 작성하는 방식이었다면, TDD는 설계 이후 바로 테스트 코드를 작성하고 테스트를 거쳐 통과하면 그대로 개발에 진행하는 방식을 거친다. 그래서 혹자는 'Test First Development' 라고도 부르는데, 이 과정을 쉽게 비유하자면 작가가 책을 쓰는 과정과 유사하다고 볼 수 있다.

1. 목차를 처음 구성한다.
2. 목차에 맞는 내용을 구상하고 초안을 작성한다.
3. 초안을 보고 수정할 내용이 있으면 계속 수정한다.
4. 수정을 마치면 본 글로 옮겨쓴다.

 뭔가 번거롭고 복잡한 듯 보이지만 이 방식을 사용했을 때의 여러 장점들이 있다.

• 코드가 내 손을 벗어나기 전 가장 빠르게 피드백을 받을 수 있다.

개발 프로세스에서 보통 '인수 테스트'를 한다. 이미 배치된 시스템을 대상으로 클라이언트가 의뢰한 소프트웨어가 사용자 관점에서 사용할 수 있는 수준인지 체크하는 과정이다. 이미 완성된 코드를 테스트한다면 문제를 발견할 수는 있지만 정확한 원인은 진단하기 힘들다. TDD를 사용하면 기능 단위로 테스트를 진행하기 때문에 모두 완성되어 프로그래머의 손을 떠나기 전에 피드백을 받는 것이 가능하다.

• 작성한 코드가 가지는 불안정성을 개선해 생산성을 높일 수 있다.

켄트 백은 'TDD는 불안함을 지루함으로 바꾸는 마법의 돌' 이라고 말했다. 이처럼 TDD를 사용하면 코드가 내 손을 떠나 사용자에게 도달하기 전 문제가 없는지 먼저 진단받을 수 있다. 이를 통해 불안정성과 불확실성을 지속적으로 해결할 수 있다.

• 프로그래머의 오버 엔지니어링을 방지한다.

기능 단위로 최소한의 코드만을 작성하고 테스트를 진행하기 때문에, 문제가 발견되지 않는 코드에 영향을 줄 수 있는 오버코딩은 하지 않는다.

• 개발 과정이 테스트 코드로 남기 때문에 과거 의사결정을 쉽게 상기할 수 있다.

TDD를 사용하면 테스트 코드를 작성하는 과정에서 히스토리가 남는다. 이를 트래킹하며 과거에 어떤 인과관계로 의사결정을 했는지 확인하기 쉽다.

 

 그렇다면 이러한 장점이 있는 TDD 방법론을 적용해보고자 하는데, 여러 방법이 있지만 그 중 오늘은 Storybook이라는 툴에 대해 다뤄보고자 한다.

 

Storybook

 Storybook은 UI 개발 도구이다. 컴포넌트 단위로 분리해 UI 테스트를 진행할 수 있으며 Storybook 서버를 통해 컴포넌트들의 실제 구현 모습을 인터랙티브하게 확인할 수 있다. 스토리북은 기본적으로 독립적인 개발환경에서 실행된다는 특징이 있으며 다양한 부가기능(addons)를 지원해 커스터마이징이 가능하다. 또한 스토리북 자체를 빌드해 배포 또한 가능하다.

 

 설치 방법은 간단하다.

# npm
$ npx create-react-app [프로젝트명] --template typescript

$ npx sb init

# yarn 
$ yarn create react-app [프로젝트명] --template typescript

$ yarn add @storybook/cli --dev

$ yarn sb init

 

실행은 다음과 같이 하면 된다.

# npm
$ npm run storybook

# yarn
$ yarn storybook

위 명령어를 실행하면 다음과 같은 화면을 6006 포트로 볼 수 있다.

그리고 설치하면 폴더와 패키지에 다음과 같이 생성된 것을 볼 수 있다.

1. 스토리북 프리뷰 세팅 폴더. 필요에 따라 redux, webpack, 웹 폰트 등의 설정을 넣어주는 곳이다.
2. 예제 폴더. 스토리북을 실행하면 확인해볼 수 있다.
3. 스토리북 의존성 패키지가 설치된 모습. 상단에 addon은 스토리북에서 제공하는 기능에 대한 패키지이다. 이 링크에서 다양한 애드온을 만나볼 수 있다.

이 중에 주요 파일들을 한번 살펴보도록 하겠다.

 

1. main.js

• storybook 전체 세팅을 관리하는 파일.
• "stories" :  해당 확장자를 가진 파일들을 모두 스토리북으로 표현하겠다는 내용이 담겨 있다.
• "addons" : 스토리북에 어떤 addon을 추가시킬지 설정하는 부분. addon은 일종의 extension인데 기존 스토리북에 추가적인 기능을 더 추가하는 것이다. addon을 설치한 후 여기에 해당 패키지명을 넣어주면 적용된다.

2. preview.js

• 일종의 app.tsx와 같은 역할을 하는 파일. 이 부분에 위와 같이 컴포넌트 최상단에 설치해야 할 Redux나 Styled-Components를 넣으면 스토리북에 적용된다.

3. Introduction.stories.mdx

• .stories.mdx 파일로 스토리북 서버에 README와 같이 문서를 만들 수 있다.
• README.md와 다른 점은 실제 페이지처럼 HTML 태그로 마음껏 꾸밀 수 있다는 점이다.

4. .stories.tsx

• 스토리북으로 컴포넌트를 테스트해볼 수 있도록 다음과 같이 실제 컴포넌트와 같은 위치에 .stories.tsx 파일을 만들어준다.

• 오른쪽 .stories.tsx 파일의 내용을 바탕으로 스토리북 서버에 다음과 같이 기능을 확인하고 테스트해볼 수 있는 항목들이 만들어진다.

 

정리

 이 글을 작성하기 전 프로젝트를 진행하면서 테스트 툴로 Jest를 써보려 했다. 하지만 막상 테스트를 해보려하니 딱히 테스트할만한 함수가 없어 어떻게 테스트해야 할지 고민이었고 그러다 이 툴을 알게 됐다. 컴포넌트는 프론트엔드 작업을 하면서 무조건 확인해야하는 부분이고, 특히 재사용하는 컴포넌트는 더더욱 잘 작동하는지, 화면에 제대로 나오는지 등을 확인할 필요가 있는데 이러한 니즈에 스토리북은 테스팅 툴로 정말 적합하고 유용한 툴이라고 생각한다. 개인적인 생각으로는 프론트엔드 개발자라면 꼭 한번쯤은 이 툴을 사용해볼 필요가 있지 않나 싶다.