{intro}
<Spacing size="lg" />
## 들어가기 전에
 
<PostImage src="https://image.aladin.co.kr/product/23618/61/cover500/k932638523_1.jpg" alt="리팩토링 2판 표지" width={500/1.5} height={615/1.5}/>
 
자바스크립트로 예시가 작성된 리팩토링 2판의 내용을 정리했습니다.
 
## 리팩토링과 테스트코드의 상관관계
 
리팩토링과 테스트코드, 도대체 어떤 관계가 있길래 한 챕터에서 테스트코드에 대한 이야기만 할까요? 일단 리팩토링의 정의에 대해 알아보겠습니다.
 
### 리팩토링이란?
 
리팩터링이란 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법입니다.
 
여기서 중요한 포인트는 겉보기 동작은 그대로 유지한다는 점입니다. 특히 버그가 보여도 리팩터링을 할 때에는 일단 무시하고 코드의 내부 구조만 변경해야 한다고 합니다. (하지만 아무도 발견하지 못한 버그라면 살짝 고쳐도 된다고 합니다🤭) 리팩토링을 하면서 기능이 변경되거나 코드가 깨지면 그것은 리팩터링이 아닌 것이죠.
 
### 리팩토링을 할 때 테스트코드의 역할
 
이때 테스트코드는 내부 구조가 변경되어도 기능이 문제 없이 동작한다는 것을 보장합니다. 작업을 하면서 수시로 테스트를 돌려 기능이 깨지는 시점을 빠르게 캐치하고 수정할 수 있으며 최종적으로 변경된 코드에 문제가 없음을 보장할 수 있게 됩니다.
 
혹시 코드를 수정하다 뒤늦게 기존 동작이 깨지는 경험을 해본 적이 있으신가요? 저는 그런 경험이 있는데요. 꽤 작업이 진행된 후라 언제부터 기능이 깨졌는지, 어느 부분이 문제인지 디버깅하느라 시간을 허비하게 되었습니다. 만약 테스트코드가 있었다면 문제가 발생할 당시에 바로 알아차려 수정할 수 있었을 것입니다.
 
이처럼 내부 구조를 손보는 리팩토링 작업을 할 때 테스트코드를 통해 불가피하게 저지르는 실수를 바로잡을 수 있습니다.
 
## 테스트코드 작성 시 중요 포인트
 
1. **모든 테스트를 자동화하고 자주 테스트하자**

책에서는 작성 중인 코드는 최소한 몇 분 간격으로 테스트하고 적어도 하루에 한 번은 전체 테스트할 것을 권장합니다. 추가한 코드에 문제가 없는지, 리팩터링을 하면서 실수한 것은 없는지 수시로 확인하며 디버깅 시간을 줄이고 코드의 안정성을 보장할 수 있기 때문입니다.
 
2. **코드를 성격에 따라 분리하자**

비즈니스 로직과 UI가 결합해 있다면 테스트코드도 자연히 복잡해질 것입니다. 이를 방지하기 위해 비즈니스 로직과 UI를 분리하는 등 성격에 따른 코드 분리가 필요합니다. 이렇게 테스트코드 작성을 위해 자연스럽게 좋은 코드를 작성하게 될 수 있다는 장점도 있습니다.
 
3. **실패해야 할 상황에서는 반드시 실패하게 만들자**

테스트코드를 작성하다 보면 테스트가 통과되는 기쁨에 취해 이 테스트코드가 정말로 요구사항을 잘 검증하고 있는지 놓칠 때가 있습니다. 때문에 일부러 테스트가 실패하는 모습을 확인하여 정말로 유의미한 테스트코드인지 확인해보는 과정이 필요합니다.
 
4. **테스트는 위험 요소를 중심으로 작성하자**

테스트코드를 도입하지 않은 경우 막막함에 아예 테스트코드 작성을 포기할 수도 있습니다. 하지만 완벽하게 만드느라 테스트를 수행하지 못하느니, 불완전한 테스트라도 작성하는 것이 낫다고 마틴 파울러는 이야기합니다. 모든 버그를 잡아낼 수 없다고 생각하여 테스트를 작성하지 않는다면 대다수의 버그를 잡을 기회를 날리는 것이라고 하면서 말이죠.
 
5. **문제가 생길 가능성이 있는 경계 조건 검사하기**

요구사항을 충족할 수 있도록 테스트코드를 작성하는 것도 중요하지만 문제가 생길만한 경계 조건을 검사해보아야 합니다. 예외나 실패가 존재하지 않은 happy path 상황에만 집중하면 다양한 예외 케이스에 대응할 수 없기 때문입니다. 함수에 인자를 넘기지 않는다거나 고객 수요 최솟값이 음수가 되는 등 범위를 벗어나는 경계 지점에서 문제가 생기면 어떤 일이 벌어지는지 확인하는 테스트코드를 작성하다보면 예외 상황을 어떻게 처리할지 고민할 수 있습니다. (마틴 파울러는 의식적으로 프로그램을 망가뜨리는 방법을 모색하며 생산성과 재미를 끌어올렸다고 합니다. 이런 게 바로 진짜 광기...?👻)
 
6. **버그 리포트를 받으면 그 버그를 드러내는 단위 테스트부터 작성하자**

충분한 테스트를 갖추었는지 판단하는 기준은 주관적입니다. 테스트 커버리지가 높다고 해서 안정적인 테스트 환경을 갖추었다고 확신할 수 없습니다. 그렇기에 '누군가 결함을 심으면 테스트가 발견할 수 있다는 믿음'을 가질 정도로 테스트코드를 구축해 둔 것 만으로도 테스트코드의 목적은 달성되었다고 할 수 있습니다.
 
## 포스팅을 마무리하며
 
이렇게 리팩토링 2판 챕터 4 ⌜테스트코드 구축하기⌟를 살펴보며 리팩토링에 있어 테스트코드가 왜 중요한 요소인지, 테스트코드 작성 시 중요하다고 생각되는 포인트들을 정리해 보았습니다. 테스트코드가 없는 환경에서 코드를 수정하며 디버깅에 애를 먹은 경험이 있기에 더욱 공감이 가는 내용이었던 것 같습니다. 이제 막 테스트코드를 공부하기 시작한 입장에서 그 필요성을 다시금 느끼게 된 계기도 되었고요. 이 외에도 좋은 코드를 작성하기 위한 꿀팁을 알고 싶으시다면 리팩토링 책을 읽어보시는 것을 추천합니다👍

Book로딩 중

리팩토링 2판 정리 - 테스트코드 구축하기