리팩터링 2판을 회사 팀 내 스터디로써 진행한다. 스터디에선 따로 책 내용을 정리를 하지 않고 주마다 정해진 분량까지 읽고 감상을 나눈다. 여기선 개인적으로 매 분량에 대한 정리와 짧은 감상을 올린다.
04 테스트 구축하기
•
리팩토링을 제대로 하려면 “불가피한 실수를 잡아주는” 테스트가 필요하다.
4.1 자가 테스트 코드의 가치
•
자가 테스트(를 가능케하는 프레임워크), CI는 이미 꽤 잘 적용된 익숙한 개념이다.
•
TDD는 더 훈련이 필요하다.
•
구현보다 인터페이스에 집중하는 것이 좋다.
4.2 테스트할 샘플 코드
•
비즈니스 로직만 테스트한다 → 중요한 부분만 테스트한다.
◦
계산하는 클래스
◦
UI, 영속성, 외부 서비스 연동 등은 제외
4.3 첫 번째 테스트
•
픽스쳐, 테스트에 필요한 객체와 데이터, 설정
•
검증
•
코드에 일시적 오류를 주입해 실패를 확인하기
◦
TDD로 개발하지 않았거나 레거시 코드라면 도움이 될거 같다.
4.4 테스트 추가하기
•
테스트는 위협 요인을 중심으로 작성해야 한다.
◦
잘못될까봐 걱정하는 영역
•
버그를 찾는데 쓰여야 한다.
•
적은 수의 테스트로 큰 효과를 보자.
•
beforeEach 같은 곳에서 표준 픽스쳐를 만들자.
◦
코드 중복은 제거하되 픽스쳐 객체 자체는 매 테스트마다 새로 만들자.
4.5 픽스쳐 수정하기
•
패턴
◦
setup - exercise - verify
◦
given - when - then
◦
arrange - act - assert
•
픽스쳐 해체(teardown)나 청소(cleanup)는 보통 테스트 프레임워크가 해줄 것으로 기대한다.
◦
생성이 너무 오래 걸려 공유하는 픽스쳐는 명시적 해체를 한다.
•
it 구문 당 가능한 하나의 검증만 하자.
4.6 경계 조건 검사하기
•
타입마다 emptiness에 대해
•
숫자라면 0 또는 음수
◦
수익이 음수? → 특이 상황
◦
의식적으로 프로그램을 망가뜨리자
•
모듈 내 중복 검증은 피하자
4.7 끝나지 않은 여정
•
단위 테스트 외에 해봐야 할 테스트 유형
◦
컴포넌트
◦
연동(integration)
◦
성능
◦
…
•
“누군가 결함을 심으면 테스트가 발견할 수 있다는 믿음"으로 작성하자.
◦
= “리팩터링 과정에서 생겨난 버그나 하나도 없다”고 확신케 하자.
느낀점
•
타입 선언과 typescript로 해결될만한 부분이 많다.
•
코드에 오류 주입: 테스트를 실패하게 만들면 되지 않나?
◦
의식적으로 프로그램을 망가뜨리자: 이것 역시 코드 수정 없이 실패할만한 테스트를 만들 수 있다.
•
타입마다 emptiness나 숫자 음수에 대해 테스트하는 것은 좋은거 같다.
•
중요하고 위협이 될만한 곳을 테스트 해야 한다 → 그 부분들을 가장 먼저 TDD 즉, 테스트부터 작성한다.
◦
새로 무언갈 시작하면서 작성하는 코드의 완전 초기 단계에서 대부분 으레 만드는 코드부터 썼던거 같다.
•
생성이 너무 오래 걸려 공유하는 픽스쳐…
◦
과거 DB를 mock하지 않고 테스트 db를 만들어 썼었다.
◦
레코드를 생성하는 api를 만들어 썼다.
◦
teardown에서 테스트 db 모든 테이블을 항상 날렸다.