배경
state management 관리를 예로 Jest, Typescript, Mocha 등등 logic testing을 하기 위한 라이브러리들이 많은데, 정작 프론트엔드에서 View(UI)를 테스트? 하는 라이브러리에는 등한시하다.
StoryBook 의 장점
Component를 Isolated 된 환경에서 개발
하나의 스토리는 다른 스토리와 완전히 독립된 state를 가지고 있기 때문에 컴포넌트 단위 개발 / 테스트가 가능하다. 스토리북을 사용하다보면 어쩔 수 없이 presentational component / container component를 나누어 설계할 수 밖에 없어진다. 이로 인해서 functional한 코드를 짜게 어느정도 강제 된다.
- Interactive 하게 UI를 개발 할 수 있다.
기존 hot-loader를 이용해서 save 할 때마다 어느정도 interactive 하게 개발을 하지만 mockState를 적용하면서 개발을 할 수 있다.
- 모듈화 된 모듈 / 페이지의 상태를 쉽게 볼 수 있다.
입력 폼 페이지를 예로 입력이 안되었을 때, validation 통과가 되지 않았을 때, 성공했을 때 등의 view 를 보기 쉽다. 디자이너와 기획자에게 보여주기 좋다.
- 특정 작업을 하기 위한 빌드업이 필요가 없어진다.
테스트를 하기 위해서 강요되는 flow가 필요 없어진다.
예를 들어 환불하는 작업을 한다고 하면
로그인 → 내 정보 보러가기 → 환불 탭 클릭 → 등등
SDD (Storybook Driven Development)
- 유저 behavior flow 를 정의하기, (프로젝트 내에서의 유저 흐름)
- 기본 적인 페이지를 스토리화 시키고, 해당 페이지에 필요한 컴포넌트를 정의하고 스토리화 시킨다.
- 최대한 Atomic 하게 설계를 시작한다. 아토믹한 단계부터 시작해서 페이지를 점차 채워나간다.
- 완성된 페이지로 flow를 완성시킨다.
참조) storybook 의 좋은점
https://www.youtube.com/watch?v=KnROzZ5Vszg&ab_channel=DongwooGimDongwooGim
StoryBook사용법
코린이