[리팩터링(2판)] CHAPTER 04 — 테스트 구축하기
3 min readOct 4, 2021
- 테스트를 작성하기 가장 좋은 시점은 프로그래밍을 시작하기 전이다. 나는 기능을 추가해야 할 때 테스트부터 작성한다. 얼핏 순서가 뒤바뀐 듯 들리지만, 전혀 그렇지 않다. 테스트를 작성하다 보면 원하는 기능을 추가하기 위해 무엇이 필요한지 고민하게 된다. 구현보다 인터페이스에 집중하게 된다는 장점도 있다(무조건 좋은 일이다). 게다가 코딩이 완료되는 시점을 정확하게 판단할 수 있다. 테스트를 모두 통과한 시점이 바로 코드를 완성한 시점이다.
hs: 요즘 DDD 를 시도하고 있다. 여기서 DDD 라 도메인 주도 개발이 아니라 드로잉 주도 개발이다. 종이에 간략한 UML 과 비슷한, 일종의 순서도를 그리며 개발하는 것이다. 순서도를 그리고 각 단계에 필요한 요소들을 TODO 로 만들어서 해결해 가며 개발한다. 어쩌면 테스트를 만들고 개발을 시작하는 것과도 비슷한 듯 하다.- 지금까지 작성한 두 테스트에는 겹치는 부분이 좀 있다. 둘 다 첫 줄에서 똑같은 픽스처를 설정하는 게 보일 것이다. 일반 코드와 마찬가지로 테스트 코드에서도 중복은 의심해봐야 하낟. 그러니 이 픽스처를 둘 모드에서 접근할 수 있는 장소로 옮겨 중복을 제거해보자. 먼저 바깥 범위로 끌어내는 방법을 시도해보자. (…중략…) 그런데 주석에 적은 것 처럼 나는 절대로 이렇게 하지 않는다. 일시적인 효과는 있겠지만, 테스트 관련 버그 중 가장 지저분한 유형인 “테스트끼리 상호작용하게 하는 공유 픽스처”를 생성하는 원인이 된다.
- 내가 이렇게 조언하면 매번 픽스처를 생성하느라 테스트가 느려지지 않냐고 묻는 사람이 있다. 눈에 띄게 느려지는 일은 거의 없다. 정말 문제가 될 때는 공유 픽스처를 사용하기도 하지만, 이럴 때는 어떠한 테스트도 픽스처 값을 변경하지 못하도록 주의한다. 또한 불변임이 확실한 픽스처는 공유하기도 한다. 그래도 가장 선호하는 방식은 매번 새로운 픽스처를 만드는 것이다.
- 그렇다면 테스트를 어느 수준까지 해야 할까? 아무리 테스트해도 버그 없는 완벽한 프로그램을 만들 수는 없다는 말은 많이 들어봤을 것이다. 맞는 말이지만, 테스트가 프로그래밍 속도를 높여준다는 사실에는 변함이 없다. (…중략…) 테스트에도 수확 체감 법칙(law of diminishing returns)이 적용된다. 또, 테스트를 너무 많이 작성하다 보면 오히려 의욕이 떨어져 나중에는 하나도 작성하지 않게 될 위험도 있다. 따라서 위험한 부분에 집중하는 게 좋다. 코드에서 처리 과정이 복잡한 부분을 찾아보자. 함수에서 오류가 생길만한 부분을 찾아보자. 테스트가 모든 버그를 걸러주지는 못할지라도, 안심하고 리팩터링할 수 있는 보호막은 되어준다. 그리고 리팩터링을 하면서 프로그램을 더욱 깊이 이해하게 되어 더 많은 버그를 찾게 된다.
- 버그를 발견하는 즉시 발견한 버그를 명확히 잡아내는 테스트부터 작성하는 습관을 들이자. 아주 중요한 습관이다! 나는 버그를 고치기 전에 항상 이런 테스트부터 만든다. 그러면 해당 버그가 다시 나타나지 않는지 확인할 수 있다. 또한 그 버그와 테스트를 계기로 테스트 스위트에 또 다른 구멍은 없는지까지 살펴본다.
hs: 테스트는 그 작성의 효율을 늘 따지게 되고, 보수적으로 접근하게 되는 면이 있는 것 같다. 아마 없어도 프로그램이 동작되기 때문이려나. 그리고 테스트의 충분함을 판단하는 것 역시 책에서 언급하듯 명확한 기준이 아닌 주관적인 판단에 의존하게 된다. 그렇지만 당연하게도 장점이 있다. 그렇기에 어떤 기준을 가지고 테스틀 작성할지 개인적으로, 또한 팀에서 일한다면 팀에서 이야기가 필요할 듯 하다.