Test-Driven Development 1부 리뷰

기본

TDD는 총 3부로 나눠지며, 첫 번째 챕터는 다중 통화 산술 프로그램을 TDD로 구현하는 내용입니다. 1부는 마치 켄트 벡의 코딩을 옆에서 지켜보는 것 같은 느낌이 들었습니다. 저자의 사고 과정, TDD의 흐름을 느껴볼 수 있죠.

이 포스트에선 책에서 나왔던 중요한 개념에 대해서 정리해 보려고 합니다.

TDD?

다음 두 가지가 TDD의 코어 룰입니다.

  1. 어떤 코드건 작성하기 전에 실패하는 자동화된 테스트를 작성하라.
  2. 중복을 제거하라.

1번 룰에서 성공하는 테스트가 되기 위해선 모든 죄악(하드코딩, 복사 붙이기 등)을 저질러도 됩니다. 단, 2번 룰에서 리팩토링(기능의 변화 없이 설계를 개선시키는 과정)을 통해 구원 받아야 합니다.

2번 룰: 중복

의존성(dependency)이 없다면 프로그램이 동작할 수도 없겠지만 그렇다고 의존성이 커지면 변경의 여파가 너무나 커져 버립니다. 그래서 의존성을 최고화 하는게 관건이고, 이 의존성이 높아지는 징후가 바로 중복(duplication)입니다.

따라서 중복을 제거해 의존성을 최소화 시킵니다.

TDD의 테스트

김창준님의 블로그에 있는 포스트 중 켄트 벡이 대답하길 2탄에 TDD의 테스트는 설계를 위한 것이다라는 문장이 있었습니다. 어제 리포트 하느라 다이어그램 그리면서 느낀건데 객체간 이런 메시지를 주고 받는다라는걸 도형으로 추상화 시킨게 다이어그램이라면 그런 추상화를 코드로 옮겨 놓은게 바로 TDD의 테스트가 아닐까 싶더라구요.

Todo

책에서 코딩하기 전 할 일을 To Do 리스트에 추가해서 관리합니다. 이것의 중요성은 매번 코딩할 때마다 느껴지더라구요.

이클립스에선 취소선이 안그어져서 뭔가 성취감이 없어요. 그래서 아예 todo 카테고리를 하나 팠죠. 이거 늘려가는 재미도 꽤 있을 것 같아요.

Once and only once (필요한 것을 하되 단 한 번만 하라)

예제를 진행하다 보면 한 호흡이 너무 짧아 보입니다. 그에 대해서 켄트 벡이 하는 말은 이렇습니다.

TDD의 핵심은 이런 작은 단계를 밟는 것이 아니라, 이런 작은 단계를 밟을 능력을 갖추어야 한다. 만약 정말 작은 단계로 작업하는 방법을 배우면, 저절로 적절한 크기의 단계로 작업할 수 있을 것이다.

죄악을 효과적으로 저지르는 방법

최대한 빨리 초록색 막대를 보기 위해 취할 수 있는 전략 세 가지.

  • 가짜로 구현하기: 상수를 반환하게 만들고 단계적으로 상수를 변수로 바꾸어 간다.
  • 명백한 구현 사용하기: 먼저 이상적인 설계를 정의해 놓고 거꾸로 구현해 나간다.
  • 삼각측량: 두 개의 테스트 예제를 가지고 구현을 일반화 시킨다.

켄트 벡은 명백한 구현을 사용해 구현하다가 막히는 부분이 있을 때 가짜로 구현하기 방법을 사용하고 어떻게 리팩토링(또는 설계) 할지 전혀 감이 오지 안 올 때만 삼각측량을 사용한다고 합니다. 삼각측량은 문제를 조금 다른 방향에서 생각해볼 기회를 제공해 줍니다.

TDD를 잘하는 방법

중복이 사라지기 전에는 집에 가지 않겠다고 약속한다.

ㅎㄷㄷ

테스트 작성 기준

적절한 테스트를 갖추지 못한 코드에서 TDD를 하는 경우 리팩토링을 하면서 실수를 해도 여전히 테스트가 통과될 수도 있습니다. 이때 어떻게 해야할까요?

있으면 좋을 것 같은 테스트를 작성하라.

테스트 인셉션

테스트 작성 도중 다른 테스트가 필요할 때가 있습니다. 이때 교리상으론 기다리는게 맞지만 켄트 벡은 작은 작업일 경우 하던 일을 중단하고 그 작업부터 먼저 끝낸다고 합니다. 단, 하던 일을 중단하고 다른 일을 하는 상태에서 그 일을 또 중단하지는 않는다고 합니다. 꿈은 2단계 까지만.

옳고 그름

코드가 맞았는지 틀렸는지 하나하나 따라가 보면서 알아낼 수도 있지만, 책에서 그것이 잘 작동할지는 테스트가 말하게 하라고 합니다. 그편이 쉽죠.

테스트 라이프사이클

기존의 소스 구조에선 필요했지만 새로운 구조에서는 필요 없게 된 테스트는 과감히 제거합니다.

테스트하기 쉬운 코드

켄트 벡은 핵심이 되는 객체가 다른 부분에 대해서 될 수 있는 한 모르도록 노력한다고 합니다. 그렇게 해야 핵심 객체가 가능한 오랫 동안 유연할 수 있고 테스트 하기도 쉬울 뿐만 아니라 재활용하거나 이해하기도 모두 쉬워지기 때문입니다.

결국 디자인 원칙을 지키는 코드가 테스트 하기도 쉽다는 말이겠죠.

보폭의 크기

개인적으로 좀 이상하기도 하고 신기하기도 했던 부분이 구체 클래스에서 중복되는 메소드를 제거하기 위해 슥 상속을 하는 부분과 시그니처가 다른 메소드를 다형성을 통해 같은 시그니처로 만들어 하나의 인터페이스로 만드는 부분 등 기존에 생각지 못했던 작은 단계를 밟는 부분이었습니다.

이런 작은 단계가 단지 일을 작게 나눠서 진행하는게 아니라 무언가 더 구체적인 흐름이나 원리를알아야 할 수 있는게 아닌가 싶었고, 테스트를 성공하기 위한 세 가지 전략에 대해서도 익숙해져야 할 것 같습니다.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중