4. 테스트 구축하기

이 포스팅은 리팩터링 2판으로 학습한 내용을 토대로 정리한 포스팅입니다.

 

리팩터링은 분명 가치 있는 도구지만, 그것만으로는 부족합니다. 리팩터링을 제대로 하려면 불가피하게 저지르는 실수를 잡아주는 견고한 테스트 스위트가 뒷받침돼야 합니다.

 

리팩터링을 하지 않더라도 좋은 테스트를 작성하는 일은 개발 효율을 높여줍니다.
(p.133)

 

4.1 자가 테스트 코드의 위치

프로그래머들이 어떻게 일하는지 가만히 살펴보면 실제로 코드를 작성하는 시간의 비중은 그리 크지 않음을 발견할 수 있습니다.

대부분의 시간은 디버깅에 씁니다.

버그 수정 자체는 대체로 금방 끝납니다.

진짜 끔찍한 건 버그를 찾는 여정입니다.

 

모든 테스트를 완전히 자동화하고 그 결과까지 스스로 검사하게 만들자.

테스트 스위트는 강력한 버그 검출 도구로, 버그를 찾는 데 걸리는 시간을 대폭 줄여줍니다.
(p.134)

 

사실 다른 사람에게 이런 식으로 개발하라고 설득하기는 녹록지 않습니다. 테스트를 작성하려면 소프트웨어 제품 본체 외의 부가적인 코드를 상당량 작성해야 합니다. 그래서 테스트가 실제로 프로그래밍 속도를 높여주는 경험을 직접 해보지 않고서는 자가 테스트의 진가를 납득하기는 어렵습니다.

게다가 테스트 작성법을 배운 적이 없는 프로그래머가 많을뿐더러, 테스트에 대해 생각조차 못 해본 이도 많습니다.

테스트를 수동으로 하면 좀이 쑤실 정도로 지겹습니다. 하지만 자동화한다면 테스트 코드를 작성하는 재미가 꽤 쏠쏠합니다.

 

테스트를 작성하기 가장 좋은 시점은 프로그래밍을 시작하기 전입니다. 나는 기능을 추가해야 할 때 테스트부터 작성합니다. (TDD 얘기 같다.)

 

테스트 방법에는 여러 가지가 있지만 이 책의 프로그래밍 언어는 Javascript이므로 모카를 사용합니다.

 

완벽하게 만드느라 테스트를 수행하지 못하느니, 불완전한 테스트라도 작성해 실행하는 게 낫다.
(p.143)

 

테스트를 너무 많이 작성하다 보면 오히려 의욕이 떨어져 나중에는 하나도 작성하지 않게 될 위험도 있습니다.
따라서 위험한 부분에 집중하는 것이 좋습니다.
...
테스트가 모든 버그를 걸러주지는 못할지라도, 안심하고 리팩터링 할 수 있는 보호막은 되어줍니다.
그리고 리팩터링을 하면서 프로그램을 더욱 깊이 이해하게 되어 더 많은 버그를 찾게 됩니다.

 

4장은 테스트 코드를 작성하는 방법에 대해서 설명하기 때문에 따로 그 부분에 대해서는 정리하지 않았습니다.

 

마틴 파울러님은 리팩터링이 중요한 만큼 테스트 또한 중요하다고 강조하고 있습니다.

 

테스트를 너무 많이 작성할 가능성도 있고, 제품 코드보다 테스트 코드를 수정하는 데 시간이 더 걸린다면, 그리고 테스트 때문에 개발 속도가 느려진다고 생각되면 테스트를 과하게 작성한 건 아닌지 의심해 봅니다.

 

따라서 주객전도가 되지 않도록 리팩터링 코드와, 테스트 코드의 비율을 적절하게 분배하는 것이 중요합니다.