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