Unify the way writing unit tests

[sungik-choi]

Description

유닛 테스트(*.test.tsx) 작성 방식을 라이브러리 전반적으로 통일합니다.

Reasons for suggestion

• 기준이 없으면 일관적인 테스트 퀄리티를 유지하기 어렵습니다. codecov의 테스트 커버리지 체크를 통해 테스트 커버리지가 낮아질 경우 머지를 막고 있긴 하나, 단순히 테스트 커버리지가 높다고 테스트 퀄리티가 높은 건 아닙니다.
• 기준이 없기 때문에, 기여자 입장에서 유닛 테스트 작성이 허들로 느껴질 수 있습니다.
• 현재 유닛 테스트의 책임이 Storybook과 겹치는 지점이 있습니다.
  • 스냅샷 테스트 등으로 유닛 테스트에서 스타일을 검증하고 있는데, 개인적으로 이 부분은 Stroybook + Chromatic으로 체크해야한다고 생각합니다. Visual test는 jsdom이 아닌 실제 dom의 스냅샷 Diff를 통해 검증하고, 유닛 테스트는 스타일 외 동작을 검증해야한다고 생각합니다.
  • 예를 들어, 유닛 테스트로는 disabled 속성이 true일시, data-disabled 속성이 존재하는지를 검증합니다. Storybook으로는 disabled 상태일 경우 스타일링(data-disabled 선택자를 통한 스타일링)이 잘 되는지를 검증합니다.

Proposed solution

1. 유닛 테스트의 책임을 명확히 정한다
2. 유닛 테스트 포맷(카테고리)을 정한다 (예: a11y, user interactions...)

현재 Jest + Testing library를 사용하는 방식에서 Storybook Interaction Test로 변경하는 것도 고려해봅시다.

What's the difference between interaction tests and using Jest + Testing Library alone?

Interaction tests integrate Jest and Testing Library into Storybook. The biggest benefit is the ability to view the component you're testing in a real browser. That helps you debug visually, instead of getting a dump of the (fake) DOM in the command line or hitting the limitations of how JSDOM mocks browser functionality. It's also more convenient to keep stories and tests together in one file than having them spread across files.

• 실제 DOM을 통해 테스트한다
• 스토리와 테스트를 한 파일에서 함께 관리할 수 있다

잘 사용한다면 큰 장점이 될 수도 있을 거 같다. (인터랙션 테스트를 피그마의 Storybook Plugin을 통해 재생 가능하다!)

References

• Implement Component Template Feature #849 의 선행작업

[sungik-choi]

https://seek-oss.github.io/braid-design-system/guides/testing-guide