리팩터링2 4장 리뷰

테스트 구축하기

드디어 나왔다. 테스트코드... 근데 이 책은 테스트에 관련된 책이 아니라서 상세하게 설명하지는 않았다. 그래서 좀 아쉽기도 하지만 테스트로 주제가 빠져버리면 책 한권으로도 부족하기 때문에 어쩔 수 없다고 생각한다. 예시 테스트 코드도 나쁘지는 않지만 좀 부족하다. 게다가 프론트엔드에서 테스트는 또 다른 얘기다.

자가 테스트코드의 가치

테스트를 작성하기 가장 좋은 시점은 프로그래밍을 시작하기 전이다. 테스트를 작성하다 보면 원하는 기능을 추가하기 위해 무엇이 필요한지 고민하게 된다. 구현보다 인터페이스에 집중하게 된다는 장점도 있다. 게다가 코딩이 완료되는 시점을 정ㄹ확하게 판단할 수 있다. 테스트를 모두 통과한 시점이 바로 코드를 완성한 시점이다.

켄트 벡은 테스트부터 작성하는 습관을 바탕으로 테스트 주도 개발 TDD(Test Driven Development) 기법을 창시했다. TDD에서는 테스트를 작성하고, 이 테스트를 통과하게끔 코드를 작성하고, 결과 코드를 최대한 깔끔하게 리팩터링하는 과정을 짧은 주기로 반복한다. 테스트-코딩-리팩터링 과정을 여러 차례 진행하기 때문에 코드를 생산적이면서도 차분하게작성할 수 있다.

특히 리팩터링을 하기 위해서는 테스트 코드를 반드시 작성해야한다. 또한 테스트할때는 경계점에 있는 부분을 위주로 작성하자.

인용구

실패해야 할 상황에서는 반드시 실패하게 만들자.

자주 테스트하라. 작성 중인 코드는 최소한 몇 분 간격으로 테스트하고, 적어도 하루에 한 번은 전체 테스트를 돌려보자.

완벽하게 만드느라 테스트를 수행하지 못하느니, 불완전한 테스트라도 작성해 실행하는 게 낫다.

문제가 생길 가능성이 있는 경계 조건을 생각해보고 그 부분을 집중적으로 테스트하자.

프론트엔드에서의 테스트

이제 프론트엔드에서 테스트를 살펴보자. 간단하게만 살펴볼거다. 테스트에대한 글은 나중에 따로 쓸 예정이다.

유틸함수 테스트

이건 하는게 맞다. 각각이 하나의 독립적인 함수이기 때문에 하지 않을 이유가 없다. jest를 이용한 테스트는 어렵지도 않다. 무조건 하자.

ui 테스트

스토리북을 테스트에 넣어야되는지 약간 애매하긴 한데... 일단 스토리북은 적용하는게 맞다. 공수에 비해 얻는 장점이 너무 크다. 그리고 시각적 회귀 테스트도 나오고 있다. 아마 몇년뒤에는 ui 테스트도 발전을 해서 이전과 이후를 비교해서 바뀐점을 찾는다던가 피그마, 제플린과 실제 화면을 비교해서 테스트하는 도구들이 나올것이다.

컴포넌트 테스트

이건 좀 애매하다. 복잡한 컴포넌트라면 테스트하기가 쉽지 않다. 거기에 api나 상태관리가 포함되어있으면 하나하나 모킹해야되고 테스트해야될 부분도 엄청 많다. 그래도 공통 컴포넌트정도라면 할만한것같다. 공통컴포넌트는 변경할 때마다 위험성이 큰데 모든 경우를 qa에게 맡길 수 없다. 큰 컴포넌트라면 테스트를 하는게 맞는지 잘 모르겠다. 위험성이 크고 중요하다면(인증이라던가 결제라던가...) 적용해도 괜찮을 것 같다. 사실 모든 경우를 테스트돌리고 싶지만 프론트엔드 특성상 변화도 너무 잦고 시간이 너무 많이 걸린다.

hooks 테스트

hooks 테스트는 경우에 따라 할만하다고 생각한다. sort나 filtering을 하는 훅을 생각해보자. 조금 복잡해지면 결과를 예측하기 쉽지 않다. 게다가 리팩터링하는 경우라면 더 큰 문제다. 이런경우 테스트를 돌리면 괜찮을 것 같다. dom과 관련되어 있지 않고 데이터만 다루기 때문에 변경점이 엄청 많지도 않을 것 같다. 그리고 변경한다면 당연히 qa가 필요할것이다.

e2e 테스트

cypress를 이용한 e2e테스트가 많이 사용되는데 꽤 긍정적이다. 모든 부분을 커버칠수는 없어도 중요한 부분이라면 천천히 도입해보는 것도 괜찮을 것 같다.

 

https://github.com/yoonminsang/refactoring-2/blob/main/yoonminsang-robin/4/a.spec.ts