Mock Object 탄생 비화(1)
사실 이 시점은 첫 번째 익스트림프로그래밍 책이 출판되기도 전이었고, 우리 같은 팀들은 무엇을 가져야 좋은 테스트인지를 포함한 - 어떻게 하면 TDD를 제대로 할 수 있는지에 대해 아직 탐험(연구) 중이었다. 특히, 나는 테스트를 용이하게 하려다 보니 객체에 “”getter”메소드를 자꾸 추가하게 되는 경향에 대해 이야기를 했는데, 사실 이런 행위가 OOP 기본 원리에 위배되는 것이어서 나는 뭔가 잘못 됐다고 느끼고 있었다. 그래서 다른 사람들은 어떻게 생각하는지 굼금해 하고 있었다.
처음에는 복잡하고 진행이 느려서, 갓 졸업한 두 명의 신입사원들이 주저했지만, 스몰토크에 익숙했던 나는 구성과 위임을 하는 전략이 옳은 방법이라는 확신을 갖게 됐다. 그리고 “no getter”규칙을 강제함으로써 자바의 객체지향 특징을 더 확실히 사용할 수 있었다. 처음 며칠 동안 힘든 시간을 보내자, 패턴이 보이기 시작했다. 우리가 하는 대화의 대부분은 원하는 값과 실제 얻은 값에 대한 이야기였고, 우리가 주입한 객체에서 expectedURL, expectedServiceName 과 같은 이름을 갖는 변수 명을 발견할 수 있었다.
또 한, 우리 테스트가 실패할 때, 뭐가 잘못됐는지 찾기 위해 step by step으로 디버그를 하는게 무척 힘들었는데, 이를 해결하기 위해서 주입된 객체가 예외를 던질 때 도움을 줄 수 있는 메시지를 포함하도록 하기 위해 actualURL, actualServiceName과 같은 이름을 갖는 변수 명을 추가하기 시작했다. 결국, 예상 값과 실제 값이 나란히 출력함으로써 문젠가 뭔지 즉시 알 수 있었다.
몇 주에 걸쳐 이런
아이디어들을 일련의 클래스 그룹으로 정제했는데, 단일 값을 위한
ExpectationValue, 순서를 갖는 목록을 위한 ExpectationList, 순서에
상관 없는 유일 값 목록을 위한 ExpectationSet 클래스가 그 결과물이었다. 텅 맥(Tung Mac)이 여기에 ExpectationCounter를 추가했는데
이는 값이 아닌 호출 횟수를 체크하기 위한 클래스였다.
이렇게 하고 보니, 뭔가 특별한 일이 일어난 것처럼 느껴지기 시작했지만, 너무 명확한 것들 처럼 보였기 때문에 설명할게 별로 없었다. 그러던 어느 날 오후 피터 마크(Peter Makrs)가 우리가 한 일에 대해 이름을 짖기로 결정했다. – 사실, 그래야 코드를 패키징할 수 있었다. – 몇몇 이름이 거론되는 와중에 명사와 동사로 둘 다 사용 가능한 “Mock” 라는 이름이 나왔고, 우리는 우리가 만든 클래스들에 Mock이라는 이름을 붙였다.
(이글의 저자 : Tim Mackinnon) - 이 아저씨 잘생겼음..ㄷㄷㄷ