테스트 주도: (3) 복사해서 쓰는 습관을 버려야한다.

연재하는 이 글들은 테스터를 위한 글이 아니라 개발자를 위한 것이며, 개발자가 어떻게 하면 테스트하면서 개발할 수 있을지에 대한 제안이다.

---

복사해서 쓰는 습관은 아주 초보적인 습관이지만, 가장 충동적인 습관이기도하다. 인류가 태어난 이후로 모방이라는 훌륭한 학습도구는 생활 전체에 아주 깊숙이 스며있는 것이기 때문에, 우리는 너무나 자연스럽게 가져다 쓰는 것에 익숙하다.

복사는 다른 사람 코드를 복사하는 것에서부터, 자신이 과거에 작성한 코드 그대로 복사에서 뿐아니라, 변수명이나 함수명을 바꿔서 복사 또는 기능을 추가하는 복사등, 그 변종도 아주 많다. 이 습관을 버리라고하는 이유의 핵심에는 "관리"에 있다.

혼자 연습하면서는 다른 사람의 것을 복사하는 것부터 시작하게된다. 그렇게 해야만 늘게되는 것은 자명하다. 그러나, 하나의 프로그램을 작성하는데 사용된 두 개의 모듈에 같은 기능을 하는 함수가 있다고 가정하자. 죄의 씨앗은 여기에서 잉태된다. 그 중 하나의 함수에서 버그가 있었고 그것을 고친 사람은 작성자가 아니었다. 그런데, 분명 문제가 되는 버그는 그 사람에 의해 고쳐졌다는 기억이 있고, 발생하는 버그를 다른 곳에서 찾다가 두*개*였*었*다는 사실을 알게 된다.

이전에도 기술한것과 비슷한데, 비슷한 일을 하는 함수가 복사되는 순간 테스트해야할 것이 두 개가 된다는 것에 있다. 똑같은 기능을 하는 것이 다른 곳에도 있다면, 다른 하나는 테스트하지 않을 것인가? 테스트 한다면 같은 테스트를 두 번 할 것인가? 이것은 같은 기능을 공유하지 않는데서 나오는 테스트 코드의 관리가 복잡해지는 원인을 제공하게 된다.

복사를 하지 않으려면, 최대한 공통적인 것을 동일한 함수로 만들어야하고, 이것이 함수호출에 대한 부담으로 이어진다면, inline 이나 define을 이용한 함수로 만들어져야 한다.

다음을 준수하면 복사하는 코드를 만드는 습관을 버릴 수 있을 것이다.

1. 외부로 노출되는 모든 코드는 테스트 코드를 꼭 작성해야한다는 생각으로 작성하라.
2. 같은 기능이 중복되는 부분이 있다면 함수로 만들고 테스트코드를 만들기 어려우면 함수의 인자들을 assert 문으로 논리적인 흐름을 명시하라.
3. 함수를 작성할 때는 항상 static을 명시하고, 다른 곳에서 필요할 때는 static을 떼고 다른 모듈로 이동하여 공유한다.
4. 함수 한 개짜리 파일도 부끄럽지 않게 작성하라.

궁극적으로 복사하지 않는 코드는 잘 설계된 계층구조가 있어야 가능하며, 복사된 코드가 많은 프로젝트는 대개 코딩에 들어가는 시점이 상세 설계가 끝나지 않았거나 상세설계가 미비한 경우에 시작하였기 때문이다.

1. 외부로 노출되는 모든 코드는 테스트 코드를 꼭 작성해야한다는 생각으로 작성하라.
외부로 노출되는 함수(static 아닌)들은 일단 테스트 대상이다. 테스터에게 "링크 가능"이라는 꼬리를 달고 건네주었으니 테스트하라는 이야기 아닌가. 또한 해당 모듈을 작성하는 개발자 입장에서도 두 개의 테스트 코드를 만들 것인데, 이것도 복사해서 테스트 할 것인가?

2. 함수의 인자들을 assert 문으로 논리적인 흐름을 명시하라.
함수란 그것이 중복사용을 위해서 분리되었건 그렇지 않건간에 논리적인 위치라는 것이 존재한다. 즉, 그 함수를 부르기 전에 선행되는 조건이 분명 존재한다. assert는 이런 조건이 항상 참인 것들을 확인 시키는 역할을 한다. 실시간에 일어날수 있는 것이 아니라 머리속 상상 실험속에서 항상 참인것에 대해 사용하는 것인데, 이것은 테스트 코드를 만들어 테스트 할 때도 중요한 것이다.

3. 함수를 작성할 때는 항상 static을 명시하고, 다른 곳에서 필요할 때는 static을 떼고 다른 모듈로 이동하여 공유한다.
static을 붙이고 함수를 작성하는 것을 습관화하라, 그리고 필요한 것들은 노출 시킨다. 여기서 필요한 것이란 설계상(설계는 함수 프로토타잎 및 그들을 컴파일하는 것까지이다.)에서 노출시키라고 한 것과, 테스트를 하기 위해 의도적으로 내놓는 것을 말한다. 그렇지 않은 모든것들은 static을 두어 그 함수를 참조하는 것이 있는지 없는지를 컴파일러 경고를 통해 확인하는 습관이 중요하다. static으로 만든 함수가 어떤 곳에서도 사용되지 않는다면, 많은 컴파일러는 경고를 준다. 그렇게 작성된 static이 다른 곳에서도 사용해야할 필요가 있다면 static을 풀게 된다.

4. 함수 한 개짜리 파일도 부끄럽지 않게 작성하라.
함수 한 개만 달랑 들어 있는 .c 파일도 있을 수 있다. 물론 이 함수는 static이 아니어야할 것이다. 이렇게 만들어지는 소스는 대개 오브젝트의 크기를 줄여 static link시에 전체 크기를 줄일 목적으로 한 개만 달랑 들어 있지만, 굳이 따로 분류될 필요가 없는 파일들을 애써 유사한 소스에 집어 넣는 것보다는 보기에도 깔끔하게 된다.

복사해서 쓰는 것이 귀차니즘의 표현이 아니라 함수로 만드는 것이 귀차니즘의 표현이다. 함수라는 것은 복사해서 쓰는 것, 디버깅하는데 어려운 것에 귀*찮*다*를 느낀 사람들이 만들어낸 훌륭한 개념이다. 역이용하지 말자.