만약 상호작용하는 컴포넌트에서 각각 상태를 관리하고 있다면

안녕하세요! albert H님

테스트 코드와 설계의 관계에 대해 문의주신 걸로 이해가 되는대요.

상황에 따라 달라질 것 같습니다.

동일한 상태 조회를 하는 컴포넌트여도, 도메인 별로 컴포넌트화가 잘 되어 있다면 구조상 테스트 코드를 작성할 때도 큰 이슈는 없을 것 같습니다.

하지만 특정 부모 컴포넌트 하위의 여러 컴포넌트에서 동일한 상태를 조회하고 수정하거나, 해당 도메인과 관련성이 적은 컴포넌트에서 계속 상태를 조회하고 변경한다면, 테스트 코드의 단위를 특정하기 모호해집니다. 이런 경우는 테스트 코드 유무를 떠나서 설계상 수정이 필요하다고 할 수 있습니다.

컴포넌트 개발에서는 도메인이나 컨텍스트에 맞게 계층화를 잘 하는 것이 중요한대요. 이 계층화를 통해 컴포넌트의 도메인을 나눈 후에는 상태에 대한 관리를 여기저기 너무 산재되지 않도록 중간 중간 상태 끌어올리기(state lift up)을 사용하여 일관된 구조를 만들고 테스트를 작성하는 것이 좋습니다.(강의의 통합 테스트 부분에서도 나오는 내용입니다!)

이런식으로 구조를 작성하면 상태를 가진 컴포넌트를 기준으로 통합 테스트를 작성하면 되고, 하위의 컴포넌트는 스토리북으로 UI가 올바르게 렌더링되는지 확인하는 형태로 명확하게 책임을 나누어 검증할 수 있습니다.

강의 서두에 나오듯이 테스트 코드를 작성하는 이유 중 하나가 이런 설계에 대한 다양한 고민과 시각을 가지도록 해주는 것인대요.

만약 컴포넌트에 대한 테스트 범주가 모호하고, 상태에 대한 검증까지 같이 하기 너무 비대해진다면, 말씀하신대로 설계에 대한 고민을 해봐야 하는 시점이라 생각됩니다.

혹시 더 궁금하신 사항이 있다면 편하게 말씀해주세요!