•
다수의 변경을 모아서 한 번의 테스트 루틴으로 안전망을 구축하려면 좀 더 상위 수준에서 테스트할 필요가 있다.
◦
한 클래스의 다수의 private 메소드의 변경이 발생했다면 이들을 가장 많이 포함하는 public 메소드를 테스트 하네스에 집어 넣어 안정화시켜볼 수 있다.
◦
다수 객체 간의 협업으로 이뤄지는 동작을 특정한 객체의 인터페이스에 대한 테스트 루틴으로 안정화시킨다.
▪
이렇게 하면 변경 작업을 위한 안전망뿐만 아니라 개별 위치별로 추가적인 리팩토링을 수행하기 위한 테스트 코드도 얻을 수 있다.
•
그렇다면 상위 수준에서 테스트 루틴을 어떻게 작성하면 좋을까? 일단 어느 위치에 작성해야 할지부터 결정해야 한다.
•
이번 장에서는 교차 지점(interception point)의 개념을 알아보고 그러한 지점들을 어떻게 찾는지 살펴보며 가장 좋은 교차 지점인 조임 지점(pinch point)에 대해서도 알아본다.
◦
이와 더불어 변경 대상 코드에 대한 테스트 루틴을 작성할 때 이것이 얼마나 유용한지 설명한다.
교차 지점
•
교차 지점은 특정 변경에 따른 영향을 감지할 수 있는 프로그램 내의 위치를 말한다.
•
이를 찾기 위해 우리는 변경이 필요한 위치들을 우선 확인한 후, 이 지점들이 외부에 미치는 영향을 추적하면 된다.
◦
영향이 탐지되는 모든 위치가 교차 지점이지만 이들 모두가 최상의 교차 지점은 아니다. 전체적인 흐름을 파악하여 최상의 교차 지점을 판단해야 한다.
간단한 경우
•
리팩토링을 간단하게 수행한 후의 객체들을 다이어그램에 집어 넣고 공개되어 있으면서 지금 변경하는 클래스와 가장 가까운 객체를 선택한다.
⇒ 여기서 해당 교차 지점에서의 깊이가 깊을수록 더 좋은 교차 지점이라는 느낌을 받았다.
상위 수준의 교차 지점
•
앞서 살펴봤듯 대부분의 경우, 변경 작업을 위한 가장 좋은 교차 지점은 변경 대상 클래스의 public 메소드 중 하나다.
◦
이런 경우는 매우 쉽지만 간혹 public 메소드가 최선의 선택이 아닐 때가 있다.
•
만약 기존 클래스의 책임이 줄어들어, 외부로 빠져나가게 된다면 변경되는 클래스의 public 메소드가 최선이 아닐 것이다.
◦
이때는 해당 클래스에서 추상화 수준을 더 높인 public 메소드에서 테스트 루틴을 작성하는 것이 좋다.
•
조임 지점은 변경 지점에 의해 결정된다는 것을 명심해야 한다. 여러 곳에서 호출되는 클래스일지라도, 이 클래스의 다수 변경에 대한 조임 지점은 한 개뿐일 수 있다.
•
영향 스케치를 통해 영향 관계를 분석하고 새로이 리팩토링하려는 그림의 조임 지점을 찾아야 한다.
조임 지점을 이용한 설계 판단
•
조임 지점은 자연적인 캡슐화의 경계다. 조임 지점을 찾았다면 코드의 상당 부분과 관련이 있는 모든 영향이 통과하는 곳을 발견한 것과 같다.
◦
조임 지점의 메소드를 디버깅해야 한다면 해당 지점에서 사용하는 클래스나 클래스 내부에 문제가 있음을 알 수 있기 때문이다.
•
조임 지점에 테스트 루틴을 작성하는 것은 어려운 프로그램 변경 작업을 시작하기에 이상적인 방법이다.
조임 지점의 함정
•
모든 기술에는 상충관계가 존재한다. 조임 지점도 그렇다.
•
단위 테스트를 작성하다보면 더이상 단위 테스트가 정의를 충족하지 못하고 통합 테스트로 나아가는 것을 볼 수 있다. 이를 조심해야 한다.
•
여기서 저자의 단위 테스트에 대한 견해가 나오는데, 저자가 생각하는 단위 테스트의 목적은 객체들이 전체적으로 올바르게 동작하는지 확인하는 것이 아니라 하나의 객체가 어떻게 동작하는지 확인하는 것이다.
◦
이 견해는 시카고/디트로이트/고전 스타일의 고립을 중요시 여긴다. 2004년 즘 나온 책이라 최근에는 견해가 바뀌었나 찾아봤더니 2019년 기준 여전히 고립을 중요시 여긴다고 트윗을 남기셨다.
⇒ 하지만 나는 개인적으로 동작 단위에 대한 검증을 단위 테스트의 목적으로 보는 런던파의 스타일을 더 선호한다.
