Test Driven Programming

테스트가 드라이브하는(주도하는) 프로그래밍

쉽게 생각하기에는 테스트 코드를 반드시 작성해야한다고 생각하기 쉽지만, 이 방법은 다음과 같은 극단적인 프로그래밍 습관의 변화를 내포한다.

1. 어떻게 사용할지 사용 형태의 샘플을 먼저 작성한다.


2. 어떤 환경설정 파일을 사용할지 샘플 환경을 작성한다.


3. 테스트해야할 함수와 테스트하지 않아도될 함수를 적절히 나누어 작성하게 된다.


4. 자동화된 테스트를 위한 로그를 작성한다.

어떻게 사용할지 사용 형태의 샘플을 먼저 작성한다.
사용되는 곳에 쓰일 샘플을 먼저 작성하지 않으면, 설계의 정확한 의도를 파악하지 못한 채 작성하기 쉽다. 만약 직접 설계한 코드를 만든다고 할 지라도, 전체적인 방향이 주먹구구일 수 있다. 즉, 필요하지도 않은 인자를 함수에 전달 할 수도 있고, 필요한 인자가 빠질 수도 있으며, 두개로 만들어야할 함수를 하나로 만들기도하고, 하나로 만들어야할 함수를 두 개로 만들 수 있기 마련이다. 코드의 주요부분은 설계를 반영하겠지만, 섬세한 부분들은 테스트 코드가 지시해야한다.

어떤 환경설정 파일을 사용할지 샘플 환경을 작성한다.
환경설정 파일에 대한 샘플은 추후에 샘플을 바꾸어 가며 다양한 환경에 대한 커버리지를 테스트할 수 있는 틀이 된다. 당신의 코드는 대부분 돌아가는데 집중하기 쉽겠지만, 테스트 샘플은 돌아갈 수 없는 상황을 재현하고, 앞으로 모든 빌드이후 테스트 되면서, 과거에 대한 확신을 심어 줄 것이다.

테스트해야할 함수와 테스트하지 않아도될 함수를 적절히 나누어 작성하게 된다.
테스트해야하는 함수는 대개 외부로 노출되는 함수이다. C언어에서는 static으로 선언된 것들은 노출되지 않으므로, 직접적인 테스트 대상이 아니다. 테스트 해야할 것이 library라면, static 함수는 .c에 전방선언으로만, 외부로 내보내야할 함수들은 .h 파일에 등록하는 습관을 기를 수 있다. 즉, 무엇보다 깔끔한 인터페이스가 만들어진다.

자동화된 테스트를 위한 로그를 작성한다.
Unit test에서는 함수의 return 값이나 referenced된 인자를 가지고 테스트하겠지만, Interface test 혹은 통합 테스트 등에서는 각 단계별로 확인할 방법이 로그를 이용한 것이다. 그저 작성된 로그는 아무렇게나 남기겠지만, 테스트 로봇을 위해 작성된 로그는 일관성이 있게 되어야하며, 쉽게 그 포맷을 수정하지 못하게 되므로 로그에 신중함과 꽉짜여진 값을 남기게 된다.