새로운 회사는 정말로 안드로이드에서 유닛테스트를 돌린다. 그러면서 추천받은 책이 테스트 주도 개발(예제로 하는) 이고, 동료가 친절히 빌려줘서 다시금 읽어 보았다.

예전과 다르게 보인 몇가지가 있다.

저자도 GUI 테스트를 경험했음에 틀림없다.

27장 테스팅 패턴을 보면, 리스너의 짭퉁 구현을 통해 리스너가 잘 불려서 notification이 잘 동작했을을 테스트 하는 코드가 있다. 저 리스너가 일반적으로 view 일테고 그런면에서 view를 추상화하고 실제 GUI와 관련 로직을 분리하여 로직을 테스트해봤음이 명백하다.

def testNotification(self):
  result = TestResult()
  listener = ResultListener()
  result.addListener(listener)
  WasRun("testMethod").run(result)
  assert 1 == listener.count

이부분이 새로운 이유는, GUI개발은 테스트와 맞지 않는다는 것에 대해 나 스스로도 상당히 많이 동의을 하고 있었고, (내) 현실과는 동떨어진 TDD라는 생각을 조금이나마 했기 때문이다.

결국, 테스트를 쉽게 할수 있게 아키텍처를 디자인함음로써 GUI를 테스트했음이 틀림없다.

값 객체에 대한 긍정적 시각

Money 객체를 바로 값 객체화 하는 부분에 대해 놀랐다.(Chapter 제목이 타락한 객체라니!) 사실 referencing 문제는 조금만 코딩 경험이 있어도 고민하는 문제인데 많은 부분을 값객체로 풀면 괜찮다는 여러 시그널들을 쉽게 무시했던거 같다. 객체를 만들때 값객체 여부를 한번더 생각해보는 습관을 가져야겠다.

나는 교차하고 합해지는 기하학적 모양들, 숫자와 함께 그 단위가 따라 다니는 단위값, 기호대수학 등 대수학 같아 보이는 상황이라면 언제나 값 객체를 사용하려는 경향이 있다.

물론 값객체에 따른 동등성과 동일성 (equals와 hashCode)등의 고려도 잘 해야겠고~

미리 고민하여 (자발적으로) 어려움에 빠지기

프로그래머들은 모든 종류의 미래 문제를 상상하는 데에 탁월하다. 하나의 구체적인 예에서 시작해서 일반화하게 되면, 쓰잘데기 없는 고민으로 때 이르게 혼동하는 일을 예방할 수 있다. 다음 테스트 케이스를 구현할 때, 이전 테스트의 작동이 보장된다는 것을 알기 때문에 그 다음 테스트 케이스에도 집중할 수 있다.

매우 탁월한 지적이다. 고민위의 고민으로 부실한 코드가 양상된다. 단단한 코드를 위해 구체적인 예시로부터의 시작은 꽤나 중요한 가이드이다.

성장

TDD가 Top-down이나 Bottom-up이 아니라 growth라는 모델이라는 접근도 설득력있다. 결국 코드를 잘 짜게 되는 것은 “성장”이고 이전에 어려웠던것이 경험을 통해 쉽게 해결할수 있게 되는 것도 성장이니까…