질문 있습니다.

안녕하세요 Raehan Jeong님~!

우선 통합 테스트 강의에서 설명하듯이 통합 테스트의 단위는 비즈니스 로직이 응집되어 있는 컴포넌트가 되어야 하는대요. 이렇게 통합 테스트 대상이 되는 컴포넌트의 경우 UI를 렌더링하기 위한 여러 작은 컴포넌트로 결합되어 있습니다. 그리고 이 컴포넌트를 기준으로 비즈니스 로직에 대한 기능 검증을 실행합니다.

이와는 조금 다르게 스토리북은 기능 검증 보다는 개발 과정에서 UI가 올바르게 렌더링되었는지 확인하기 위한 도구입니다. 즉, 스토리북은 비즈니스 로직을 검증한다 보다는 UI를 확인한다 라고 할 수 있는대요. 그렇기 때문에 통합 테스트 단위와 스토리북 단위는 같을 수도 있지만 다른 경우가 더 많을 것 같습니다.

예를 들어 예매한 영화 티켓의 정보를 보여주는 컴포넌트가 있고 가정해보겠습니다.

이 컴포넌트에서는 API를 통해 티켓의 정보를 보여줘야 하며, 티켓 확인 버튼을 누르면 사용 완료 같은 문구를 보여줘야 할텐데요. 이런 다양한 비즈니스 요구 사항을 통합 테스트로 검증할 수 있습니다. 만약 예매한 영화 티켓의 정보를 보여주는 컴포넌트를 대상으로 스토리북을 작성한다면 API부터 상태 변경까지 모두 모킹하거나 별도의 조작을 통해 스토리를 작성해야 하는데요. 이렇게 되면 스토리 작성 작업에 대한 비용도 커지며, 원하는 스토리를 만들어 UI를 확인하는데에도 불필요하게 많은 시간이 소요됩니다.

결국 예매한 영화 티켓의 정보를 보여주는 컴포넌트도 예매 버튼, 티켓 정보를 보여주는 타이틀 등의 여러 컴포넌트들로 구성될텐데요. 이런 컴포넌트들은 UI를 보여주는게 전부이며 별도로 검증할 만한 로직들이 없습니다.

prop으로 받은 정보를 렌더링하는 정도의 역할만 하기 때문에 단위 테스트를 작성하는 것이 크게 의미가 없고 오히려 스토리북으로 UI만 빠르게 확인하는 것이 좋습니다. 필요하다면 이런 presentational 컴포넌트들을 조합하여 스토리로 만들어 확인할 수도 있구요.

(그렇기 때문에 컴포넌트 설계 시 통합 테스트 단위와 UI 확인 단위를 명확히 나누는 것도 굉장히 중요하다고 강의 후반부에 이야기합니다..!)

결과적으로 스토리북과 통합 테스트는 서로 확인하려는 목적이 다르기 때문에 단위가 다를 수 있습니다.

말씀하신 내용중에 통합 테스트를 스토리북과 같은 도구와 함께 하라는 것이 아니라, 통합 테스트로 상태에 따른 동작을 검증하고, 그 안에 있는 각각의 컴포넌트들은 스토리북 안에서 스타일과 레이아웃이 틀어지지 않는지 확인하라는 것이 강의의 목적에 좀 더 부합하는 방향으로 보입니다.

혹시나 이해가 안가거나 더 궁금한 사항이 있으시다면 편하게 말씀해주세요~!