테스트 주도: (2) 모듈 블럭이 명확해야한다.

모듈화에 대한 개념은 초창기 분할 컴파일에서부터 시작하여, 동적 라이브러리, 나아가 플러그인, 자동화 객체와 같은 고급기능까지 비슷한 개념에서 출발하여 찬란한 꽃을 피운(?) 분야이다.

어떻게 모듈에 들어가는 함수들을 선택해야할까, 즉 어떤 함수들을 외부에서 사용하게 만들까. 그것에 대한 기준을 테스트 관점에서 바라보면 다음과 같다.

1. 외부로 노출된 함수들은 모두 테스트한다.
2. 모듈은 관련있는 기능(함수)들만을 모아 놓아야 한다.

테스트하지 않을 함수들은 모두 file scope을 가지게한다. 즉 C 언어로 말하면, static 한정자를 붙여서 외부에서 참조가능하지 않게한다. 왜 이것이 중요하냐면, 외부에서 전혀 사용하지 않는 것들이 외부로 노출될 경우 함수이름 공간에 불필요한 것이 들어가게 되고 정작 같은 이름의 중요한 함수와 충돌이 일어날 수 있기 때문이다.
유닉스/리눅스의경우 nm 명령을 통해 대문자 "T" 속성을 가지게 되는 것들은 모두 global scope를 가진 노출된 함수들이다. 이들은 모두 테스트 코드에서 사용 되어 일련의 테스트에 참여해야한다.

모듈에 들어 있는 함수들이 연관성이 있어야한다는 것은, 예를 들어 인명 사전 같은 라이브러리가 있다고 할 때, 내부에서 소문자로 만들어 비교한다고 가정하면 소문자화하는 함수가 외부에서도 필요할 것 같은 느낌에 static을 제거하고 외부로 노출하는 경우가 발생한다. 만약 그렇다면 이것은 새로운 모듈로 그 함수를 이동시켜야지 아무 연관 없는 모듈에서 외부로 노출되어서는 안되는 것이다. 이런 모듈은 테스트관리가 어렵게 된다.

넓은 의미에서 모듈이라는 것은 설계시에 독립된 단위를 뜻한다. 그것이 라이브러리일 수도 있고, 실행 파일일수도 있고 실행 파일 집합일수도 있고, 스크립트가 될수도 있고 웹페이지 집합이 될 수도 있다. 독립된 단위로 설계되어 독립된 사람이 개발할 수 있고, 독립된 테스트 케이스를 만들수 있는가를 고려하면 적절한 모듈로 나눌 수 있는 연습이 가능하다.

같은 맥락에서 모듈테스트라는 것은 외부로 노출되는 기능, 즉 그 모듈이 외부에서 사용되는 것에 대한 테스트를 말하는 것인데, 그 기능이 이 모듈에 조금 저모듈에 조금 들어 있다면 그것은 설계부터 잘못된 것이다.

모듈 테스트 코드는 그 흐름이 간결하고 힘차다! 모듈이 단순할 수록 이런 환호성을 기대하게 되며, 설계자에게 박수를 보내게 된다.