Refactoring/Building Test Code

리팩토링을 위한 필수적인 선행조건은 견고한 테스트를 하는 것이다. 당신이 리펙토링을 자동으로 해줄 수 있는 툴을 가지고 있다고 하더라도 여전히 테스트가 필요하다. 모든 가능한 리펙토링을 자동으로 해주는 툴이 나오는데는 오랜 시간이 걸릴 것이다.

나는 이것을 단점으로 보지 않는다. 나는 내가 리펙토리를 하는 중이 아니라 하더라도, 좋은 테스트는 프로그래밍 속도를 비약적으로 향상시킨다는 것을 발견했다. 이것은 많은 프로그래머들의 통념과는 반대된다는 점에서 놀라운 것이다. 그렇기 때문에, 왜 그러한지에 대한 이유를 설명할만한 가치가 있다.

[edit]

The Value of Self-testing Code ¶

프로그래머들이 시간을 쓰는 것을 가만히 살펴보면, 실제 코드를 쓰는 시간은 작은 부분이고 대부분의 시간을 디버깅에 소비한다. 그리고 버그를 찾는 데 많은 시간을 보내고 수정하는 것은 금방이다. 모든 프로그래머들은 버그를 찾느냐고 밤새었던 이야기들을 하나 둘 이상은 가지고 있을 것이다. ^^; 게다가 버그 하나를 잡아도 여전히 다른 곳에서 버그가 생길 가능성이 있다. 이렇게 되면 버그를 잡는데 많은 시간을 소비한다.

나로하여금 self-testing code로의 길을 시작하게 한 계기는 OOPSLA '92의 한 이야기부터였다. 그때 누군가 (아마도 Dave Thomas)"클래스는 자기 자신의 테스트코드를 가지고 있어야 한다" 라는 말을 했다. 이 말은 테스트를 구성하기 위한 좋은 방법으로 여겨졌다. 나는 모든 클래스에 클래스 스스로를 테스트하는 메소드들 (test라 한다.)들을 가지도록 만들었다.

그때 나는 increment development단계에 있었고, 나는 매번 increment 을 완료할때 클래스들에 test method들을 추가했다. 그때 했던 프로젝트는 꽤 작았었고, 우리는 우리의 increment 주기는 한주 단위정도였다. 테스트의 실행은 는 꽤 수월하게 되었다. 하지만 테스트들은 실행하기 쉬웠지만, 테스트를 하는 것은 여전히 지겨운 일이였다. 이것은 내가 체크해야 하는 모든 테스트들이 console 에 결과를 출력하도록 만들어졌기 때문이다. 나는 꽤 게으른 사람이고, 나는 일을 피하기 위해 꽤 열심히 일을 준비했다. 나는 이 클래스들이 프린팅 해주는 것을 체크하는 대신, 컴퓨터가 테스트를 수행하도록 했다.내가 할일은 테스트 코드에 내가 기대하는 결과를 작성하고, 그 비교를 수행하는 것이다. 자, 나는 모든 클래스들의 test method를 수행할 수 있었고, 모든 일이 잘 되면 단지 'OK' 가 출력되는 것을 확인하면 되었다. 이 클래스는 지금 스스로 자기 자신을 테스트를 했다.

모든 테스트가 자동화되었는지 확인하고 테스트들의 결과를 테스트 코드 스스로 체크하도록 해라.

이제 테스트는 컴파일 만큼이나 간단해졌다. 나는 컴파일 할 때 마다 테스트를 했다.그리고 곧 나는 버그를 바로바로 찾아낼 수 있었다. 나는 내가 디버깅을 하는데 그리 많은 시간을 소비하지 않았음을 알게 되었다. 만일 내가 이전 테스트에 의해 주의하도록 한, 버그가 있는 코드를 추가했을 경우, 테스트를 실행할 때 바로 볼 수 있었다.

이 사실을 알아갈수록 나는 테스트에 좀 더 적극적이 되었다. increment가 끝가기를 기다리는 대신에, 나는 조그마한 기능을 추가할 때 마다 테스트를 했다. 매번 나는 새 기능들을 추가 했고, 그들에 대한 테스트들을 수행했다. 이 당시 나는 디버깅에 수분이상을 소비하지 않았다.

test suite는 버그를 찾는 시간을 줄여주는 강력한 버그 탐지기이다.

물론 다른 이들로 하여금 이 과정을 따르도록 설득하는 것은 쉽지 않다. 테스트 코드를 만드는 것은 그 양이 많다.
그리고 이것이 실제로 프로그래밍 속도를 높인다는 것을 경험해보지 않으면 self-testing 코드는 사람들이 이해해주지 못한다. 그리고 테스트가 수동이라면 이것은 지루할 것이다. 하지만 테스트가 자동화된다면 테스트 코드를 쓰는 것은 꽤 재미있는 일이 될 것이다.

사실 테스트 코드를 작성하기 위한 가장 좋은 때는 프로그래밍을 시작하기 전이다. 어떤 기능을 추가해야할 때, 테스트 코드를 작성하는 것으로 시작한다. 이것은 뒷걸음질 치는 것이 아니다. 그 기능을 추가하기 위해서 어떤 것들이 행해져야 하는지 스스로에게 물어보는 것이 된다. 그리고 테스트 코드를 쓰는 것은 구현보다는 인터페이스에 집중할 수 있게 해준다. (그리고 이것은 언제나 좋은 것이다)

테스팅 코드는 ExtremeProgramming 의 중요한 부분이다. Beck, XP. 이 이름은 빠르고 게으른 해커같은 프로그래머들에겐 마술주문과 같을 것이다. 하지만, extreme programmer들은 테스트에 대해 매우 헌신적이다. 그들은 가능한 한 소프트웨어가 빠르게 발전하기 원하고, 그들은 테스트들이 당신을 아마 갈 수 있는 한 빠르게 갈 수 있도록 도와줄 것을 안다.

이정도에서 이야기는 충분하다 본다. 비록 내가 self-testing code를 작성하는 것이 모두에게 이익이 된다고 생각하더라도, 그것은 이 책의 핵심이 아니다. 이 책은 Refactoring에 관한 것이다. Refactoring은 test를 요구한다. 만일 Refactoring 하기 원한다면, test code를 작성해야 한다.

Refactoring