[책읽기] 테스트 주도 개발 - 켄트백 지음, 김창준 강규영 옮김.

몇일전 테스트 주도 개발이라는 책을 다 읽었다.

1장부터 16장까지는 은행에서 사용하는 돈(통화)에 관련된 작업을
어떻게 TDD로 만들어 가는지를 실제 코드를 보여주면서 보여주고 있다.

17장 부터는 TDD 자체에 대한 이야기로 되어 있다.

이전에 적었던 부분을 빼고, 책을 읽으면서 줄쳐 놓은 부분을 옮겨 본다.

• 이러한 접근 방식은 "깔끔한 코드" 부분을 먼저 해결한 후에, "작동하는" 부분을 해결해 가면서 배운것들을 설계에 반영하느라 허둥거리는 아키텍쳐 주도개발과는 정반대다.

• 시스템이 크다면, 당신이 늘 건드리는 부분들은 절대적으로 견고해야 한다. 그래야 나날이 수정할때 안심할 수 있기 때문이다.

• "다음에 할일은 무엇인가?"에 관련된 또 다른 질문은 "어떤 테스트들이 추가로 더 필요할까?"다.

• 그리고 지금 이 글을 쓰는 동안 "Expression(수식)" 메타포를 생각했는데, 설계가 기존과는 완전히 다른 방향으로 흘렀다. .... Expression 메타포는 중복되는 통화를 합치는 세세한 일단의 문제에서 날 해방시켰다. 나는 수식의 성능에 대해 우려 했지만 최적화를 시작하지 전에 어느정도의 사용 통계를 볼때까지 기다리는것에 만족한다.

• 아주 확신에 찬 사람과 정말 얼렁뚱땅 넘어가는 사람들 제외한다면, 아무리 작은 변화라도 테스트 하지 않고 릴리즈 하지 않는다. ( 만든것만 테스트하는 임시 테스트 코드 )

• 당신이 변화를 테스트 할 수 있다고 해도, 실제로 변화를 테스트하는 것은 "테스트를 가지고 있다."는 것과 똑같지 않다. ( 계속 유지되는 자동화된 테스트 )

• 이 경우엔 '테스트'를  '자동화된 테스트'로 치환하면 된다. "내가 이걸 고치면 뭔가 다른 부분을 망가트리지 않았을까?" .... 자동화된 테스트가 있다면 스트레스를 받기 시작할때 테스트를 실행할것이다. .... 테스트를 실행하면 즉시 좋은 느낌을 받게 되고 그러면 작업중에 에허를 낼 일도 줄게 되며, 스트레스도 적어진다.

• 테스트를 실행하는 것이 서로 어떤 식으로 영향을 미쳐야 좋은가? 아무 영향이 없어야 한다. .... 앞 부분에서 실행된 테스트가 실패한 후 그 영향으로 다음 테스트부터는 시스템이 예측 불가능한 상태에 놓이는 경우가 허다하다.

• 테스트는 전체 애플리케이션을 대상으로 하는것 보다 좀 더 작은 스케일로 하는것이 좋다. 어쨌건 주된 교훈은 각각의 테세트는 다른 테스트와 완전히 독립적이어야 한다는것이다. 즉, 문제가 하나면 테스트도 하나만 실패해야하고, 문제가 둘이면 테스트도 두개만 실패해야 한다.

• 테스트를 언제 작성하는것이 좋을까? 테스트 대상이 되는 코드를 작성하기 직전에 작성하는것이 좋다. 코드를 작성한 후에는 테스트를 만들지 않을것이다.

• 시스템을 배갈할 때 무슨 일 부터 하는가? 완료된 시스팀이 어떨 거라고 알려주는 이야기 부터 작성한다. ( USER STORY를 말한다. 기존의 방법론의 요구사항 문서와 비슷한데 훨씬 짧고 비격식적이다. )

• 테스트 할 때 어떤 데이터를 사용해야 하는가? 테스트를 읽을 때 쉽고 따라가기 좋을 만한 데이터를 사용하라. .... 1과 2 사이에 어떠한 개념적 차이도 없다면 1을 사용하라.

• 시스템이 여러 입력을 다루어야 한다면 테스트 역시 여러 입력을 반영해야 한다.

• 길을 잃은 느낌이 들땐 어떻게 해야 할까? 코드를 다 지워버리고 처음부터 다시 해 보자.

더 많은 내용에 줄을 그어 놓았지만, 그만 옮겨적어야겠다.


아직은 "테스트 주도 개발"에서 "테스트"에 대해서만 와 닿았고, "주도"에 대해서는 잘 모르겠다.
다음에 정리를 다시하면서 "주도" 부분도 다시 한번 알아 봐야 겠다.