Refactoring - 테스트 구축하기

본 내용은 마틴 파울러의 Refactoring 2판을 토대로 작성되었습니다.

테스트 구축하기

• 리팩터링을 제대로 하려면 불가피하게 저지르는 실수를 잡아주는 견고한 테스트 스위트가 뒷받침 되어야 함
• 리팩터링을 하지 않더라도 좋은 테스트를 작성하는 일은 개발 효율을 높여줌

 

1. 자가 테스트 코드의 가치

• 실제 코드를 작성하는 시간의 비중은 그리 크지 않음
  • 대부분의 시간은 디버깅에 사용
• 모든 테스트를 완전히 자동화하고 그 결과까지 스스로 검사하게 만들자
  • 컴파일할 때마다 테스트도 함께 실행
  • 생산성이 급상승, 디버깅 시간이 크게 줄어듦
• 테스트를 자주 수행하는 습관 가지기
  • 버그가 발생한 지점은 조금 전에 작성한 코드에 있음
• 테스트 스위트는 강력한 버그 검출 도구로, 버그를 찾는 데 걸리는 시간을 대폭 줄여줌
• 테스트를 작성하려면 소프트웨어 제품 본체 외의 부가적인 코드를 상당량 작성해야 함
• 테스트를 작성하기 가장 좋은 시점
  • 프로그래밍을 시작하기 전
  • 기능을 추가해야할 때 테스트부터 작성하기
  • 테스트를 작성하다보면, 원하는 기능을 추가하기 위해 무엇이 필요한지 고민
  • 인터페이스에 집중하게 된다는 장점
  • 테스트를 모두 통과한 시점이 바로 코드를 완성한 시점
• TDD(Test Driven Development)
  • 처음에는 통과하지 못할 테스트를 작성
  • 테스트를 통과하게끔 코드를 작성
  • 코드를 최대한 깔끔하게 리팩터링
  • 위 과정을 짧은 주기로 반복
  • 테스트 - 코딩 - 리팩터링 과정을 한 시간에도 여러 차례 진행하기 때문에 코드를 대단히 생산적이면서도 차분하게 작성 가능

 

2. 첫번째 테스트

• 테스트 프레임워크
  • Jest, Mocha
• 테스트에 필요한 데이터와 객체를 뜻하는 픽스처(fixture: 고정장치)설정
• 픽스처의 속성들을 검증
  • 어서션(assertion: 단언, 확인) 라이브러리 사용
  • JavaScript를 다룰 때는 expect를 주로 사용
• 실패해야 할 상황에서는 반드시 실패하게 만들자
• 자주 테스트하기
• 테스트는 위험 요인을 중심으로 작성
  • 단순히 필드를 읽고 쓰기만 하는 접근자는 테스트할 필요가 없음

 

3. 테스트 추가하기

• 완벽하게 만드느라 테스트를 수행하지 못하느니, 불완전한 테스트라도 작성해 실행하는 것이 나음
• 매 테스트에서는 다른 픽스처를 사용해야 함
• 공유 픽스처를 생성시키면, 픽스처를 사용하는 또 다른 테스트가 실패할 수도 있음
  • JavaScript에서 const는 객체의 내용이 아닌, 객체를 가리키는 참조가 상수임을 뜻함
  • 테스트 결과가 제멋대로 되어 테스트의 신뢰도가 떨어짐

 

4. 픽스처 수정하기

• 한 구문에서는 한가지 속성을 검증할 것

 

5. 경계 조건 검사하기

• 범위를 벗어나는 경계 지점에서 문제가 생기는 것을 고려하여 테스트 작성
• 프로그램에서 특이 상황을 어떻게 작성해야할 지 생각하기
• 문제가 생길 가능성이 있는 경계 조건을 생각해보고 그 부분을 집중적으로 테스트하기
• 실패(falilure)
  • 실제 값이 예상 범위를 벗어남
• 에러(error)
  • 검증보다 앞선 과정에서 발생한 예외 상황

 

6. 끝나지 않은 여정

• 단위 테스트
  • unit test
  • 코드의 작은 영역만을 대상으로 빠르게 실행되도록 설계된 테스트
  • 자가 테스트 코드의 핵심
  • 자가 테스트 시스템은 대부분 단위 테스트가 차지
• 컴포넌트 사이의 상호작용에 집중하는 테스트, 스프트웨어의 다양한 계층의 연동을 검사하는 테스트, 성능 문제를 다루는 테스트 등이 있음
• 제품 코드보다 테스트 코드를 수정하는 데 시간이 걸리면, 테스트를 과하게 작성한 것
  • 대부분의 경우는 테스트가 너무 적음