해결된 질문
작성
·
337
1
답변 1
1
안녕하세요~ 우선 좋은 질문 주셔서 감사합니다!
말씀하신 대로 'ClassName props으로 설정한 css class 가 적용된다'는 굉장히 간단한 기능이고, 별도 분기 처리도 없기 때문에 테스트가 크게 유의미하진 않습니다.
하지만 단위 테스트의 의도와 목적을 보여주기 위해 className
이란 prop을 받아 스타일을 설정하는 기본적인 기능까지 테스트 코드로 작성해두었습니다. 단위 테스트를 작성하여도 css 스타일이 실제로 올바르게 브라우저에 렌더링되는지는 확인(jsdom에서 렌더링되기 때문)할 수 없지만, 특정 prop에 따라 css class가 추가되거나 제거되는 것은 컴포넌트의 기능이기 때문에 단위 테스트로 검증하는 것이 필요합니다.
이러한 의도를 전달하고 싶어 추가한 테스트인데..지금 보니 예제가 너무 간단해서 와닿지 않을 수도 있겠네요..!
만약 실제 프로덕션 앱에서도 별도 조건 처리 없이 className만 그대로 받아 렌더링하는 정도면 말씀하신대로 생략해도 무방한 테스트 코드입니다.
하지만 실제 프로덕션 앱의 컴포넌트 내부적으로 여러 조건에 따라 스타일이 추가되거나 빠지는 경우가 있을 수 있는대요. 그런 경우에는 분기 처리에 따라 스타일이 달라져야 하기 때문에 반드시 테스트 코드로 검증하는 것이 필요합니다!
혹시나 다른 의견이 있거나 더 궁금한 사항이 있으시면 얼마든지 댓글로 남겨주세요 🙂
기본적으로 eslint나 타입스크립트와 같은 정적 분석 도구를 사용하면 함수의 인자나 리턴 값, 선언된 변수의 타입, 조건문 등 로직 작성 단계에서 발생할 수 있는 다양한 오류를 개발이나 리뷰 단계에서 방지할 수 있습니다. 실제로 이러한 도구의 등장으로 예전처럼 코드 상에서 타입 체크를 위한 방어 코드를 작성하는 일도 많이 사라지게 되었구요.
그렇기 때문에 말씀하신 것처럼 a() 함수를 호출하면 문자 타입의 데이터를 반환한다
와 같은 type 체크 테스트는 작성하지 않는게 좋을 것 같습니다. a()
함수의 내부 로직 실행 결과로 인한 기대값은 당연히 테스트로 검증해야 하지만, type이나 문법상 잘못 동작할 여지가 있는 부분은 이미 정적 분석 도구를 통해 코드 작성 단계에서 충분히 사전 검증되었다고 할 수 있습니다.
말씀하신 내용과 비슷한 맥락으로 강의에서도 명확한 타입의 props만 받아 별도 복잡한 로직없이 UI만 렌더링(jsx 리턴)하는 presentational 컴포넌트에 대해서는 테스트 코드를 전혀 작성하지 않습니다.(이 내용은 강의 후반부 통합 테스트에서도 이야기합니다..!)
xxiiuu 님도 새해 복 많이 받으세요! 😀
답변 감사합니다~~~
설명 덕분에 좀 더 이해가 되었어요. 제가 아직 강의를 뒷부분까지 듣지 않아서 혹시 뒤에서 설명해주실 수도 있을 것 같긴하지만ㅠ 지금 들으면서 궁금한 점은 질문 드리고 갈게요. 타입스크립트를 쓰는 경우에 일반적으로 props나 리턴 값이 타입스크립트 type으로 명확하게 정의가 된다면 테스트를 생략해도 될 것 같다는 생각이 드는데요. 중요하고 비싼 비지니스 로직이거나 복잡한 코드라서 테스트를 붙여서 검증해야한다는 기본 전제는 빼고 생각했을 때요... 가르침 부탁드리겠습니다.. 새해 복 많이 많이 받으세요!