해결된 질문
작성
·
291
1
안녕하세요! 강의를 듣고 테스트 코드를 연습중에 질문이 있어서 글을 작성하게 되었습니다.
제가 테스트 코드를 작성하려는 프로젝트에서 공용 컴포넌트 중 Pagination 컴포넌트에 유닛 테스트 코드를 작성하려고 합니다.
제가 생각한 테스트 흐름은 실제 유저가 Pagination 컴포넌트의 화살표 버튼 클릭시 현재 페이지가 1이 증가하는 것처럼 테스트 코드를 구현하려고 했습니다.
하지만 Pagination 컴포넌트에는 setCurrentPage 함수를 주입 받아서 처리하기 때문에 유닛 테스트에서는 클릭으로 current page 값이 증가하는 것을 확인할 수는 없고 spy 함수를 통해 setCurrentPage가 실행되는 것까지만 확인하는게 맞는건가요??
두서없는 글 읽어주셔서 감사합니다!
답변 1
0
안녕하세요! 우선 강의 들어주셔서 감사합니다.
우선 페이지네이션 컴포넌트 자체에서 말씀해주신대로 테스트를 작성할 수도 있겠지만, Spy 방식으로 테스트 할 경우 아래와 같은 문제가 있어 권장하지는 않습니다.
특정 함수가 호출되었는지만 알려줄 뿐, 올바르게 동작하는지는 말해주지 못한다.
대상 시스템의 상세 구현방식을 활용한다는 점
그럼에도 해당 테스트 방식이 적합한 사례는 다음과 같은데요.
실제 구현이나 가짜 객체를 이용할 수 없고, 상태 테스트가 불가능 한 경우 대비책으로 특정 함수가 호출된다는 확신으로 진행한다.
함수 호출 횟수나 순서가 달라지면 기대와 다르게 동작하는 경우 상태 테스트로는 검증이 힘들기 때문에 적합할 수 있다.
페이지네이션 컴포넌트가 위 사례에 해당하지 않는다면, 올바르게 렌더링 되는지 스토리북을 통해 시각적으로 검증하고 해당 페이지네이션 컴포넌트를 사용하는 부분에서 통합 테스트를 통해 올바르게 동작하는지 검증할 것 같습니다.
혹시 도움이 되셨다면 다행인데 추가적으로 궁금한 내용이 있으시다면 남겨주세요!
스토리북에서는 함수 기능에 대한 테스트를 할 수 있는 방법이 존재하지만 강의에서는 따로 소개를 해드리고 있지는 않습니다! 대신 시각적인 부분 검증하는데 사용을 권장하고 있는데요. 실제 페이지를 이동하는 부분은 E2E 테스트를 사용하면 실제 동작처럼 검증할 수 있으니 E2E를 사용하는 것이 좋을 것 같습니다.
2부 마지막 부분에서 각 테스트에 대한 검증 범위와 역할을 정리하고 있는데요. 해당 부분을 다시 한 번 들어보시면서 위 사례에 대해 고민해보시면 좋을 것 같습니다!
감사합니다.
답변 주셔서 너무나 감사합니다!!
말씀해주신 것 처럼 제가 생각한 페이지네이션 테스트 방식은 통합 테스트를 통해 전역 상태를 모킹해서 진행해야 할 것 같습니다. 또는 말씀해주신 것 처럼 스토리북을 이용해서 시각적으로 검증을 해야할 것 같습니다.
그렇다면 스토리북으로 단순 UI 렌더링을 통해 마크업을 확인할 뿐만 아니라 페이지가 제대로 이동하는지와 같은 기능 부분도 스토리 내에서 상태를 만들고 함수를 주입해서 테스트하는 경우도 많은가요?!