make coverage report
•
istanbul•
c8•
jest coveragecoverage reporter
•
coveralls•
codecovcoverage CI
•
github action
Current Code Coverage
1.
2021.05.07 기준 66.18%
첫 codecov 리포트. 그래도 이전에 테스트를 많이 추가해놔서 커버리지가 그렇게 낮은 편은 아니었다.
2. 2021.05.14 기준 74.91%
지난주 대비 8.73% 올랐다. 내가 테스트 커버리지 높이겠다며 테스크 코드를 작성하는 것을 보고, 동료 개발자도 PR을 날릴 때 테스트 코드를 작성해서 올렸다. 좋은 변화다. 후후.
test 추가하면서 배운 것들
3.
puppeteer에서 특정 타입 resource만 로드하는 방법(image, document 등)
4.
•
puppeteer mockup 만들기(테스트할 function 에서 puppeteer가 쓰인 부분만)
code
•
puppeteer-core 패키지 mocking 후, puppeteer를 쓰던 대로 쓰면 된다.
code
5.
codecov bash upload
code
6.
BDD
•
describe-context-test
◦
describe: 테스트 대상
◦
context: 특정 상황, 상태
◦
test: 구체적으로 기대하는 기능
•
Client Test
2021.05.18 화요일
클라이언트 테스트를 작성하면 좋은 것. e2e 테스트나 스타일 확인할 때 빼고는 로컬에서 실행해 확인할 필요없이 테스트만 실행하면 된다. 또한 개발 중일 때도 테스트를 watch 해놓으면 계속 버그나 기능 구현에 피드백을 받을 수 있다.
•
관심사의 분리: 페이지 내 리스트가 있다면 리스트 컴포넌트로 분리하고 테스트도 따로 한다.
◦
react의 관심사: state reflection. 상태를 반영하는 것에 관심이 있지, 상태 관리에 관심 있는 것은 아니다.
◦
redux의 관심사: state management
◦
SRP(single responsibility principle): 단일 책임 원칙을 지켜 관심사를 분리하고 테스트를 쉽게 작성한다.
◦
ListContainer: list에 대한 상태관리
•
BDD
◦
상황에 따라 기대되는 행위를 기술하는 것
◦
describe, context, it
◦
context는 jest-context 라이브러리 사용
•
TDD란?
◦
TDD를 잘하려면 설계를 잘해야 하고, 설계를 잘하려면 TDD를 잘해야 한다.
◦
TDD는 '지뢰 탐지기'다
◦
지금 개발하는 기능에 대해 테스트를 붙이는 것은 쉬우나, 나중에 거대해진 코드에 대해 테스트를 작성하는 것은 어려운 일이다. TDD를 하는 것은 미래의 고통을 현재로 가져오는 기술이다.
◦
요구사항을 명확하게 하는 습관 → 요구 사항이 명확하지 않으면 테스트를 작성할 수 없다.
◦
예제로서의 스펙
•
App.tsx 테스트
◦
App 테스트는 비대해지는 경향이 있어서 e2e 테스트로 대체 중
