다라쓰 프로젝트 2개중 하나인, 댓글 모듈의 jest 테스트 커버리지가 평균 70%가 넘었습니다.
구문 커버리지: 82.13%
분기 커버리지: 61.6%
함수 커버리지: 71.17%
라인 커버리지: 82.28%
으로, 평균 74.295%의 커버리지가 나왔습니다. (원래는 16%였습니다 ㅎ)
커버리지가 70%이상이 되면, 그 이상부터는 (좋긴하지만) 유의미한 효과가 없다는 글을 보았기 때문에 목표를 70%로 잡았었는데, 다행히 시간을 갈아넣어서 달성했습니다.
사실, 테스트 파일 1개에 아무 유틸이나 테스트한다면, 유틸 1개만 테스트하는 것이므로 커버리지 100%가 나옵니다.ㅎ
하지만 저는 전체적인 프로그램의 테스트코드를 확인하기 위해서
거의 모든 컴포넌트와, 거의 모든 커스텀 훅에 대해 테스트 코드를 작성했습니다.
그렇게 145개의 테스트 코드가 작성되었습니다.
구문, 라인 커버리지는 단 한번만 실행되기만 하면 높아지는 수치이기 때문에, 달성하고자 한다면 그렇게 어렵지는 않았고,
분기 커버리지와 함수 커버리지는 생각보다 달성하는 것에 제약이 많았습니다.
예를 들어, 커스텀 훅 내부에 useEffect가 있다면, useEffect 내부의 코드를 실행하기 위해서, 해당 커스텀훅을 테스트용 리액트 컴포넌트에 넣어서 실행해야 합니다.
또한, iframe간 통신을 하고 있어서, window,postMessage으로 mesage이벤트를 감지해서 동작하는 부분들,
에러 예외처리부분들이 테스트가 완벽하게 되지 않았습니다.
이렇게 디테일한 부분들은 추후에 유지보수하면서 잡아야겠습니다.
또한, 이렇게 테스트 커버리지 향상을 위해 노력을 하면서,
테스트 코드를 어떻게 하면 잘 작성할 수 있을까 계속 고민을 하다보니, 결국엔 코드를 테스터블하게 작성하는 것이 가장 테스트 코드를 잘 작성하는 방법이라는 느낌을 받았습니다.
또한 mocking이 쉬워지는 코드를 작성하고, jest의 mocking과 관련된 메서드들을 잘알아야겠다고도 느낌을 받았습니다.
커스텀훅으로 모든 함수를 분리했다가, 다시 되돌리기도 하고
디렉토리 구조를 전면 변경하기도하고.. 코드에 드러날진모르겠지만 일주일동안 열심히 고민했습니다.
pr을 날리려하니 이렇게 보이는군요.
기능을 똑같지만, 코드상으로는 거의 재건축 수준의 난이도였던것 같습니다.
이번 경험을 통해서 저만의 테스트 원칙을 세워보았습니다.
- 테스트는 리팩터링 및 기능 추가/수정에 대한 개발자의 자신감을 향상시켜준다.
- 함수를 잘게 쪼갤 수록, 테스트 하기 쉬워지고 선언적인 코드를 작성할 수 있다. (하지만 찾아가서 유지보수하기 힘듦)
- 함수의 역할을 1가지로 고정한다. (여러 역할을 하는 코드일 수록 테스트 코드를 작성할때 고려해야할 사항이 많아진다.)
- useEffect, useState 처럼 리액트 컴포넌트 내에만 쓰이는 함수들은 리액트 컴포넌트 내에서만 쓰자. 테스트할때 리액트 컴포넌트까지 고려해야한다.
- 컴포넌트를 크기별로 나누어야 테스트할때 모킹하는 순서를 맞출 수 있다. (갑자기 큰 컴포넌트에 대한 테스트 코드를 작성하려고하면, 작은 단위의 컴포넌트에서 사용하는 커스텀훅에 대한 mocking이 필요할 수도 있음)
- jest의 mocking과 관련된 메서드들을 기억하자.
- 컴포넌트는 상태관련로직을 바깥에서 주입하고, 자신은 렌더링 로직만 담당하는 것이 테스트하기 편하다.
- 테스트 코드는 테스트 대상과 가깝게 유지한다. (물리적인 거리가 멀어지면, 테스트 코드 동기화가 심리적으로 되지 않는다.)
- 클린코드에서 좋은 테스트 코드가 나온다.
- re-export는 생각해본다. 모킹할때 경로를 정확히 입력해야할 경우가 있기 때문에,
- path-aliasing을 사용한다. 컴포넌트의 위치가 바뀌었을때 import 경로때문에 터지는 일을 줄이자.
- 인터페이스 인자로 Dispatch<>처럼 일반적이지 않은 타입의 인자를 사용하지 않는다. (mocking할때 너무 힘들다.)
- __mocks__ 수동모의를 적극 사용한다.
이제 다라쓰의 또 다른 프로젝트인 백오피스 관리자 페이지의 테스트 코드를 작성해야겠습니다.
버그도 잡고, 기능도 추가하고, 면접 준비도하고, 테스트 코드도 작성하고, 리팩터링도 하고!
https://github.com/woowacourse-teams/2021-darass/pull/674
[FE][댓글모듈] jest 테스트 커버리지 평균을 70%이상으로 유지한다. by zereight · Pull Request #674 · woowa
모든 컴포넌트 + 거의 모든 hook에 대해 테스트 코드를 작성했고 구문, 분기, 함수, 라인 커버리지 평균 74.295%
github.com
'개발 > 개발 리포트' 카테고리의 다른 글
| 2021/10/09 : 텍스트의 자동 개행처리 (0) | 2021.10.10 |
|---|---|
| 2021/10/08 : 시크릿 모드에서는 localStorage를 사용하지 못한다, jest에서는 --detectOpenHandles 옵션을 사용한다. (0) | 2021.10.09 |
| 2021/10/06 : localStorage, setTimeOut의 테스트는 생각보다 간단하다. (0) | 2021.10.07 |
| 2021/10/05 : 수동모의를 사용하자 (0) | 2021.10.06 |
| 2021/10/04 : 테스트코드는 테스트대상과 가깝게 유지한다. (0) | 2021.10.05 |
