[책]테스트주도개발(Test-Driven Development by Example)

테스트 주도 개발 - 켄트 벡 지음, 김창준 외 옮김/인사이트

게으름으로 인해 근 한달 만에 이 책을 읽었습니다.

어쩌면 이 책의 내용은 39p 에 나오는 다음 내용이 다 입니다.

 

1.     재빨리 테스트를 하나 추가한다.

2.     모든 테스트를 실행하고 새로 추가한 것이 실패하는 지 확인한다.

3.     코드를 조금 바꾼다.

4.     모든 테스트를 실행하고 전부 성공하는 지 확인한다.

5.     리팩토링을 통해 중복을 제거한다.

 

이게 다라니 허무하죠? ^^;

저자는 위와 같은 방법을 좀더 구체적으로 설명하기 위해 간단한 화폐 클래스 예제(전부 다 완성된 코드가 2바닥 정도 밖에 안 되는)를 가지고 약 100 페이지를 할애해서 장황하게 설명을 하고 있습니다. (양장 책이 좀 아깝습니다)

 

처음에는 아직 클래스도 만들어지지 않은 단계에서, 화폐 클래스가 있다고 가정하고 화폐 클래스를 사용하는 테스트 프로그램을 만듭니다.  

이 코드는 당연히 컴파일 오류가 날 것이고, 켄트 벡(책의 저자)는 컴파일 오류가 안 나오는 최소한의 코드를 추가합니다.

최소한의 코드란, 가짜 화폐 클래스를 만들고, 테스트에서 사용하는 Method가 있을 경우 해당 Method 에서 Assert 오류가 나지 않도록 참이 되는 상수를 리턴하는 식으로 해서, 가급적 컴파일 에러만 모면하는 코드를 만듭니다.

이렇게 되면, 결국 클래스 생성자와, 간단한 인터페이스를 구현하는 것과 동일한 결과가 됩니다. (저는 솔직히 요 과정이 조금 짜증났습니다. ‘그냥 클래스와 인터페이스를 미리 구현하고 테스트하면 될 텐데’ 라는 의문이 책 마지막까지 가지게 되더군요)

이와 같이 수정한 후 오류가 발생되지 않는 코드가 완성되면, 테스트를 조금 더 보강합니다. 이 테스트도 통과하는 코드가 만들어지면 리팩토링을 통해 중복을 피하고 깨끗한 코드를 만듭니다. 이 과정을 반복하는 것이 TDD 개발 방식이라고 이 책을 방금 다 읽은 저는 이해했습니다. ^^;(책을 다 읽었는데 머릿속이 좀 멍하네요. 더워서 그런가)

 

TDD 의 테스트를 제대로 하기 위해서는 할 일 목록을 잘 관리해야 하는데요. 이 목록은 다음과 같이 작성합니다.

-       테스트해야 할 항목을 TO DO LIST 식으로 목록화 시켜 만듭니다. 테스트를 꼼꼼히 하기 위해 앞으로 만들거나, 테스트해야 하는 클래스가 어떤 식으로 코딩 되어야 할지, 어떤 테스트가 필요할지를 설계하고 이를 간단하게 몇 줄로 기록합니다.

-       그리고는 이 TO DO LIST 중 가장 만만한 부분부터 공략해 들어 갑니다. 쉬운 작업부터 위의 1~5번 과정을 거친 후 하나가 해결되면 해당작업이 완료되었음을 표시합니다. (취소선으로 표시)

-       하나의 테스트가 완료되면 다음 할일 목록을 골라 위 과정을 반복합니다.

 

어찌 보면 이 방법은 일반적으로 개발자가 개발하는 방식과 많이 유사합니다.

개발자는 이 책에서 말하는 것과 같이 먼저 테스트코드를 만들지는 않더라도, 코딩 하기 전에 만들고자 하는 클래스가 어떤 식으로 작동할지 명세를 가지고 작업에 들어가기 마련입니다. 보통은 개발자가 직접 만들지 않고 명세만 만드는 사람들이 따로 있거나 PM 이 이를 대신하는 경우가 많은 걸로 압니다.

테스트 해야 할 목록이라고 하는 게 어찌 보면, 코딩 해야 할 상세 명세서에 있는 내용인 셈인데요.

이렇게 따지만 TDD 는 그다지 새로울 게 없는 프로세스 같습니다. (처음부터 테스트 코드를 만드는 건 새롭습니다 ^^)

 

내가 지금까지 써온 기술적인 글은 모두 전문가의 행동과 비슷한 행동을 생성해내는 근본적 규칙을 찾으려는 노력에 대한 것이었다. (321P)

 

우수한 개발자가 어떠한 식으로 개발하는 지를 보고, 그 개발하는 방식을 구구단과 같이 공식화시키는 작업들이 리팩토링이었고, 패턴이었고, 또 TDD로 나온 것 같습니다.

이미 많은 개발자들이 경험적으로, 따로 배우지 않았음에도 TDD 도 일부 하고 있고, 패턴도 어느 정도 하고 있으며(몇 가지 패턴들은 코딩을 몇 년 하다 보면 굳이 배우지 않아도 이미 실천하는 경우가 많죠), 리팩토링도 하는 경우가 많습니다.

 

이 책에서 설명하는 TDD 도 완전히 새로운 개발방식이라기 보다는, 개발을 위한 좋은 가이드라고 생각하는 게 좋겠습니다.

이 책(TDD) 역시 그와 같은 맥락에서 바라본다면, 책의 내용중 전체가 아니더라도 배울만한 습관을 찾아서 자기 것으로 만드는게 중요하리라 생각됩니다.

 

다만 책에 있는 내용을 읽다가, 일부 내용들은 마지막까지 제가 생각하는 부분과 상충되어서 머리 속을 혼동되게 하더군요.

-       윈도우에서는 일반적인 서버 프로그램과 달리, 특정 이벤트의 발생 순서에 의해 문제가 발생하는 경우가 많습니다. (테스트로 작성하기 힘든 코드가 많습니다). 이러한 경우를 모두 감안해서 문제가 생기지 않는 테스트 코드를 만들 수 있을까요?  단순히 피보나치 수열처럼 0, 1, 1, 2, … 가 되어야 한다는 테스트 코드를 만들기는 쉬어도, 이벤트의 수와 순서가 너무나 많은 윈도우 프로그램의 경우 이 모든 과정을 테스트에 담을 수 있을지 의문이 듭니다. GUI 에 TDD 를 적용할 수 있느냐는 책 뒤편에서도 논란의 여지가 있다고 나오더군요. (P 328).

-       제대로 된 테스트목록을 만드는 게 중요한데요. 이 부분은 명세가 잘 되어야 하는 것으로 꼭 개발자의 몫은 아니라고 생각됩니다. 개발을 하다 보면 계속해서 사용 범위가 확대되고, 엮이게 되는데 이 경우 테스트 목록도 다시 만들고, 다시 코딩하고 리팩토링 과정을 반복하는 게 쉬울까 의문이 듭니다. 또한 명세에 없는 항목들은 결국 테스트에서도 빠지게 되고 해당 기능의 잘못 구현될 가능성도 생깁니다. 이로 인해 발생하는 문제를 TDD 가 보장해 주질 못할 텐데.. 결국 설계의 문제를 TDD 가 보장하지는 못하는 게 아닌가 싶습니다.

-       최소한의 코드만 만들고 다시 컴파일, 다시 리팩토링, 다시 테스트를 하는 과정은, 어찌 보면 시간낭비다 싶을 정도로 어리석어 보였습니다. 명세를 보는 순간 대략적인 인터페이스와 코드를 만들 수 있기 때문에 TDD 식으로 개발하는 게 정말 코딩 속도가 빨라질 지 의문이 갑니다.(켄트 벡이 저보다 백만 배 더 훌륭한 개발자라는 건 인정하지만)  100 페이지 가량 위와 같은 방식으로 계속해서 코드를 수정하는 과정을 읽고 있자니 정말 갑갑하더군요. 처음부터 방향을 제대로 잡으면 될 텐데 조금씩 수정하고 리팩토링하고 --;; 저랑은 잘 안 맞는 부분이었습니다.

-       TDD를 잘 하려면 결국 리팩토링과 패턴을 잘 해야 합니다. 무슨 말이고 하면, 테스트를 통과할 정도의 코드는 누구나 만들 수 있습니다. 핵심은 아무렇게나 테스트를 통과하도록 만든 클래스에 대해 중복을 제거하고 깨우침이 있는 클래스로 만드는 작업은 결국 리팩토링이라는 기술을 사용해야만 가능하기 때문입니다. 리팩토링은 별도의 책으로 나올 정도로 책의 분량이 많은데, 결국 TDD 는 리팩토링에 상당부분 의존적이라는 생각입니다.

 

쓰고 보니 부정적인 내용이 많았는데요.

TDD 자체가 문제라기 보다, 제 개발 방식이 이미 특정한 틀에 오래 갇혀 있어 다른 개발방법을 받아 들이기 힘들어서 인 것도 같습니다. 어린 아이처럼 거부반응 없이 많은걸 그대로 받아 들일 수 있다면 좋을 텐데요.

 

다른 분들의 서평을 보니, 책을 읽고 한 1년쯤 지났을 때 어느 순간 이 책의 진가가 느껴지더라는 얘기도 있고 하니, 책의 내용을 곱씹으면서 제가 개발하고 있는 환경에 어떤 식으로 적용해야 할지 고민해 봐야겠습니다.

 

Daum 블로거뉴스에서 이 포스트를 추천해주세요. [추천]