스토리북 한 줄 정리

컴포넌트를 자유롭게 그리고 공유하는 스케치북

스토리북을 도입하게 된 계기

• 프론트엔드 협업과정에서 여러 사람들이 공통 컴포넌트들을 만들게 된다.
• 이때 협업시 서로가 짠 공통 컴포넌트를 보려면 코드로만 확인할 수 있다.
  • 아무리 설명을 잘 적어도 코드로만 보면 이게 어떤 컴포넌트일지 알기가 매우 모호하다.
• 컴포넌트를 만들때 잘 작동하는지 확인하려면 따로 테스트 페이지를 파서 렌더링해보고 확인해봐야된다.
  • 이에 따라서 그 컴포넌트가 잘 작동하는지 확인하는게 번거롭다.

스토리북의 이점?

• 컴포넌트의 문서화

  • 단순히 코드뿐만 아니라 **실제 컴포넌트의 UI 동작 방식**을 공유할 수 있다.
  • 이 때문에 재사용성이 높은 컴포넌트를 설계하기 유리하고 협업 시 소통의 비용을 낮출수 있다.

• 컴포넌트에 대한 테스팅

  • 수동 테스팅 (우리가 눈으로 보는 것?)
  • 테스트 코드 작성을 통한 자동 테스팅
    • jest, testing-library 를 같이 사용할 수 있다.

[번역] 왜 2022년에는 스토리북일까요?

컴포넌트 문서화

UI 테스팅