TOC
참고
본 내용은 단위 테스트의 기술을 읽고 정리한 내용입니다.
책의 내용과 함께 개인적인 의견과 생각, 학습을 담아 작성하였습니다.
들어가며
레거시 코드 환경에서는 TDD가 어렵다.
- 기존 코드를 대상으로 테스트를 작성하는 것은 어렵다.
- 기존 코드를 리팩토링하는 게 거의 불가능하거나 그럴 시간조차 없다.
- 일부 개발자는 본인이 설계한 코드를 바꾸려 하지 않는다.
- TDD를 활용할 수 있는 도구가 부족하다.
- 어디에서부터 시작해야 할지 판단하기 어렵다.
그래서 레거시 코드를 작업할 때는 이런 문제를 해결해야 한다.
- 해야 할 일이 너무 많을 때, 테스트를 어디에서부터 시작하고 어느 부분에 더 집중해야할지
- 테스트가 없는 상태에서 기존 기능을 망가뜨리지 않은 채 어떻게 안전하게 코드를 리팩토링할지
어디에서부터 테스트를 시작해야 할까?
테스트가 가장 필요하거나 시작하기 좋은 컴포넌트부터 우선순위를 결정해야 한다. 다음은 우선순위 결정의 고려사항이다.
논리적 복잡도- 순환 복잡도(cyclomatic complexity) 라고 한다.
- 컴포넌트 내의 논리 구조의 복잡성
- 중첩된 if 문, switch 문, 재귀 호출 등
- 다양한 도구를 활용해서 자동으로 측정할 수 있다.
- SonarQube, CodeClimate 등
의존성 수준- 컴포넌트가 의존하는 외부 요소 수
- 현재 앱 외부의 이메일 서비스나 연동된 DB, 정적 로그 등
우선순위- 컴포넌트가 프로젝트 내에서 차지하는 중요도
무엇을 선택할지 결정
쉬운 것부터 시작
장점
- 초기 테스트 작성이 훨씬 빠르고 수월
단점
- 시간이 지남에 따라 테스트하기 어려운 컴포넌트들만 남음
- 프로젝트가 끝나갈 때(출시 직전 치열할 때) 가장 어려운 테스트가 남음
학습곡선 고려
- 팀이 단위테스트에 익숙하지 않다면 간단한 컴포넌트부터 시작
- 팀원 개개인의 테스트 역량 키워서 복잡한 컴포넌트도 이겨내기
어려운 것부터 시작
장점
- 팀원들이 이미 단위 테스트 경험이 있다면 이점
- 테스트를 위해 리팩터링할 때마다 컴포넌트의 의존성이나 다른 컴포넌트의 테스트 관련 문제도 함께 해결 가능
- 의존성이 많은 리팩터링은 시스템의 다른 영역에서 긍정적인 영향
단점
- 테스트 작성 경험과 역량이 뛰어나야 처음부터 가능
리팩터링 전에 통합 테스트 작성
리팩터링 이후에 기존 기능이 제대로 동작한다는 보장이 필요하다!
이를 위해 운영 시스템에 대한 통합 테스트를 미리 작성하는 것이 좋다.
리팩터링 시나리오
- 원래 시스템이 정상 작동하는지 확인하기 위해 통합 테스트 (목이나 스텁 없이) 추가
- 시스템에 추가하려는 기능에 대해 실패하는 테스트를 작성하거나 리팩터링 시작
중요한 점은 수정하거나 기능을 추가해야 할 부분에만 집중하는 것이다.
