이번에는 React Class Component -> React Function Component로 바꾸는 연습이였어요!
16.8 고마워🙇♂️🙇♂️🙇♂️🙇♂️ 이제야 숨통이 트이는군요!
export default function Calculator() {}
------vs------
const Calculator = () => {}
export default Calculator;
🤔 어느 것이 더 좋을까요?
function을 썻을때 장점이 없으니 (prototype, lexical scope, hoisting, etc..) arrow function을 쓰는게 맞지 않을까요?
추가적으로 타입스크립트 상으로 function보다 arrow function이 type 폼을 만들기가 더 쉽다고 하셨어요.
Vallista님께서 커스텀훅을 만들 때 테스트 -> 커스텀훅 작성 -> 리팩토링
이 순서대로 작성을 해보라고 추천을 하셨어요.
import { renderHook, act } from '@testing-library/react-hooks';
위의 라이브러리를 사용해서 테스트를 진행했습니다.
관련 커밋
하지만 테스트를 진행하면서 매개변수가 이벤트인 경우 깊은 생각이 들더라구요.
🤔 내가 테스트를 위한 코드를 작성하고 있는 것은 아닌가?
(커스텀 훅 내부에서) e를 인자로 받아 e.target.textContent만 사용하는 메서드들은 테스트를 위해 매개변수를 e -> string으로 변경해서 테스트 했습니다.
흠... 테스트를 위한 원본 코드 수정?
❓ 아래와 같은 고민들이 들더라구요.
1. 정상 동작하는 코드를 단순히 테스트만을 위해 수정해도 될까요? (매개변수를 e -> string으로 변경해야만 했음)
2. 매개변수로 이벤트 자체를 받는 것이 더 범용성 있다고 생각이 드는데 어떻게 생각하시나요?
3. 매개변수가 e인 메서드를 테스트할 수 있나요?
우리는 "왜 테스트를 해야하는가" 부터 정의를 해볼께요.
사실 크게 테스트가 필요 없는
로직입니다."어떤 case를 넣었을 때 calculate에서 어떤 에러
가 나와야 한다"가 더 맞겠죠.❗ 정상케이스는 어차피 상태 저장이니 react에서 테스트를 잘 했을꺼고,
그 외 케이스를 보기 위함히니까요.
그런 관점에서 테스트 케이스를 작성하실때 접근하면 좋겠습니다!
이런 관점에서 작성하면, 추후 테스트코드만 보고도 어떤 로직을 어떻게 사용하는지 파악할 수 있고 어떤 요구사항이 필요한지 기획적 정책 기록도 함께 볼 수 있겠죠?
테스트의 목적 === 100% coverage 달성? 아닙니다.
위에 언급해주신, 매개변수가 e 인 메서드를 테스트에 대해 고민을 하셨는데요! "이게 필요한 테스트일까요?"
테스트에 무언가 고민이 들게 되었다는 것은, 두 가지 신호로 볼 수 있습니다.
1) 명확하지 않은 테스트를 진행하려한다.
2) 테스트가 필요가 없을 수 있다.
테스트 모듈은 대다수의 테스트를 커버
할 수 있도록 개발하였습니다. (테스트 모듈을 믿으세요!)
그런데, 현재 테스트 수준에서 무언가 문법적이나 혹은 무언가 엣지 케이스를 대응하기 위해 고민을 하게 된다? 👉 그 부분은 테스트가 필요없는 부분일 가능성이 높습니다.
사실 "confirmExit(window confirm + localStorage 저장)" 같은 친구들은 테스트가 필요 없습니다. 특수한 로직이 있는게 아니거든요.
테스트 할 메서드는 "비즈니스 로직이 있는 테스트가 필요한 로직"
을 해주시면 되겠습니다!
무엇을 테스트할 것인가? 👉 비즈니스 로직이 있는 테스트가 필요한 로직
정상 동작뿐만 아니라 에러 케이스들
에 대해서도 고민
"어떤 케이스를 넣었을때 calculate에서 어떤 에러가 나와야 한다"
👇
input과 return에 대해서 정확히 판단
👇
내부로 들어올, 외부로 나갈 인터페이스를 먼저 고려한 테스트 작성
💪 vallista님 덕분에
커스텀 훅,
의미있는 테스트,
사용성,
프로젝트 내 모든 파일에 대한 검토 등
정말 많은 것을 얻고 가는 것 같아요!!