There are 1 articles in 'TDD'
  1. 2006/09/05 테스트 주도 개발

2006/09/05 22:14

테스트 주도 개발

XP 의 여러가지 방법 중의 한가지로 Test Driven Development 를 뜻한다. 대안언어축제에서 자극을 받아서 책을 보기 시작했다. 그전에도 한번쯤 봐야지 생각은 몇번 했지만, 그런 생각에서 실제로 책을 도서관에서 빌리기 까지는 상당히 먼 거리였나보다.
갑자기 바뀐 생활리듬에 아직도 적응을 못하는지 도서관에서는 계속 정신을 차리지 못하고 졸지만, 그래도 하루만에 100페이지가 넘게 책을 읽은 것을 보면, 책이 정말 쉽게 쓰여졌고 번역또한 매끄러운게 틀림없다. 근데 이책은 그냥 이렇게 읽어서는 안되고 가능한 천천히 읽는 것이 더 도움이 될 듯 싶다. 그리고 아무리 천천히 읽는다고 해도, 그냥 읽는 것 보다는 직접 TDD를 실행해보지 않으면 일주일 정도만 지나고 나면 지금의 감흥은 이내 사라지고 말거다.
TDD의 주요한 다섯단계는 아래와 같다.
  1. 테스트 작성
  2. 컴파일 되게 하기
  3. 실패하는지 확인하기 위해 실행
  4. 실행하게 만듦
  5. 중복 제거
첫단계가 여기서 가장 중요한 개념이 아닌가 싶다. 코드를 작성하기 이전에 코드를 테스트 하기 위한 테스트 코드를 먼저 작성하는 것이다. 테스트 코드는 주로 assert() 와 같은 것을 이용하여 조건을 만족시키지 못하면 즉시 프로그램을 abort 시키는 것들이다.
테스트 코드가 완성되었다면 해당 테스트들을 만족시키기 위해서 코드를 작성한다. 처음부터 잘 작성하려고 해서 두려움을 키우기보다는 일단 돌아가면 된다는 식으로 코드를 작성한다. 극단적으로 assert( Dollar(10) == Dollar(5).plus(Dollar(5) ) 의 테스트를 통과하기 위해서, plus() 메쏘드에 위의 테스트만을 통과하기위한 하드코드를 작성하기도 한다. 정말 놀라움을 금할 수가 없었다. 그러나 여기서 멈춘다면 쓰레기 코드와 직장에서의 해고만이 있을 뿐. 일단 테스트 코드를 만족하는 것을 확인한 후에, 좀 더 일반적인 경우에도 돌아가도록 코드를 수정한다. 단 코드 수정시간은 가능한한 짧게 유지한다. 즉 지금 즉시 build 를 했을 때, 에러없이 컴파일 되는 상태를 green 이라고 하고, 그렇지 못한 상태를 red 라고 한다면, 가능한한 red 인 상태에서의 시간을 짧게 유지하는 것이다. 코드를 고치는 데 오래 걸릴 것 같으면, 다른 부분을 먼저 수정하거나 어떻게 해서든지 그 시간을 줄인다. 그리고 해당 테스트 케이스를 모두 만족시키면 또 다른 까다로운 테스트 케이스를 넣고, 그것을 만족시키기 위해 절차를 반복한다.
이런식으로 코드를 고쳐나가면서 리팩토링하여 점차 코드를 수정해 나가면, 그동안 작성한 테스트 케이스를 모두 충족하는 훌륭한 코드가 만들어 진다는 게 TDD 의 개념이다.
이것을 행하여 얻는 이점으로는 멋지고 훌륭한 코드를 만들어 내야 한다는 막연함과 두려움에서 어느정도 벗어날 수 있다는 것이며, 견고한 코드를 작성할 수 있다는 점이다.
그러나 타고난 귀찮음을 극복하지 못한다면 이것역시 소용이 없다.
또한 책에서는 자바를 이용해서 코드를 개선시켜나가고, 클래스를 개선할 때, 디자인 패턴의 개념은 독자가 미리 알고 있다고 가정한다.( 그래서 읽다가 디자인 패턴책도 다시 봐야하나 하는 생각이 들었다)
아무런 것에도 쫓기지 않으면서 도서관에서 한가로이 책을 읽을 수 있다는 것이 이렇게 즐거운 줄 미쳐 몰랐다. 그렇지만 이제 그럴 수 있는 시간이 얼마 남지 않았다는 것이 아쉬울 따름이다.

2006/09/05 22:14 2006/09/05 22:14
[top]