unit test에 대한 생각

급한 프로젝트를 진행하면서 항상 갈등에 빠지는 것이 있습니다.

unit test를 만드느냐, 만들지 않느냐, 아니면, 어느정도 까지 만드느냐...
보통은 위와 같은 갈등을 하다가... 바쁘니까(^^)  주어진 시간이라는 리소스를 설계와 개발에 집중을 하기 위해서 다음을 기약합니다.

그런데 프로젝트를 진행하다보면 unit test를 만들어 뒀으면 좋았을 경우를 자주 만나게 됩니다.

1. 다른 사람 또는 다른 팀에서 전달해 주는 라이브러리를 사용하는 경우 해당 라이브러리를 사용하기 전에 라이브러리를 체크하기 위해 각 인터페이스에 대한 unit test를 만들어 두었다면,
1. 해당 라이브러리에 의해 발생할 수 있는 다양한 삽질을 미연에 방지하여 리소스를 절약 할 수 있습니다.
2. 라이브러리 배포 시점에 간단하게 한번만 돌려서 이상 여부를 리포트 할 수 있습니다. 이또한 리소스 절약이 될 수 있네요.
3. 만약 사용하는 사람이 n명 이라면 절약된 리소스 * n 정도가 절약 될 수 있겠네요.
2. UI시나리오 별로 unit test를 만들어 두었다면,
1. 프로그램의 형상을 유지하기 쉽다. 즉, 수정작업에 의해 발생할 수 있는 side-effect를 unit test에 의해 막을 수 있습니다.(물론, 어느정도의 unit test를 구성해 뒀느냐에 대한 차이는 있습니다.^^)
1. QA검증을 할 수 있는 프로젝트 환경이라면, 더 큰 필요성이 느껴집니다. 그 이유는 side-effect에 대한 비용이 너무나도 크기 때문입니다. 비용은 아래와 같습니다.
1. QA인력이 테스트 하여 이슈로 등록한다.
2. (여러 프로젝트가 같이 진행되는 환경이라면) 프로젝트 관리자들에 의해 해당 이슈가 누구의 이슈인지 구분되어야 한다.
3. 구분된 이슈는 각 프로젝트 개발자가 확인하여 해당 이슈가 자신의 이슈인지 다른 프로젝트의 이슈인지 확인해야 한다.
4. [반복] 중간 중간 QA인력 또는 프로젝트 관리자에 의해 이슈가 어떤 상태인지 관리가 되어야 한다.
5. [반복] 관리되는 이슈는 weekly 회의와 같은 회의를 통해 보고되고, 논의되어야 한다.
2. UI시나리오에 대한 설계서를 조금더 꼼꼼하게 검토해서 구현하게 되는 부가적인 이점을 가질 수 있습니다.
1. QA검증 이슈에 등록되지 않아서 위에서 언급한 2-1-1에서 발생하는 리소스를 절약할 수 있습니다.
3. 배포 이전에 개발자가 수행할 수 있는 레벨의 테스트를 자동으로 수행할 수 있다.

우선은 생각나는 대로 unit test를 만들어 두었다면 좋았을 만한 점들을 정리해 보았습니다.

사실은 정리된 점들 뿐아니라 자신이 만든 프로그램에 대한 자신감, 애착을 가질 수 있고, 개발 초기단계 부터 unit test를 생각하면서 설계에 들어 간다면, 테스트를 위해 각 모듈이 분리되는 것에 의해 프로그램이 자연스럽게 커플링이 줄어드는 설계 및 구현이 될 수 있다라는 장점도 가지게 됩니다.

  마지막으로 unit test에 대한 제 생각을 정리해보겠습니다.
프로토타입을 통한 데모를 보여줘야 하는 프로그램이 아니라면, 전체 프로젝트의 리소스 절약차원에서 반드시 필요합니다. 그렇다고, (경험상) 프로젝트 관리자가 unit test를 위한 일정을 주려고는 하지 않습니다. 따라서, 개발자가 자신의 시간을 쪼개어 unit test 에 대한 경험을 조금씩 늘여 가면서 unit test set을 구성하는 시간을 줄여 가는 노력이 필요합니다. 그렇게 경험을 쌓아 가다보면 짧은 시간에 unit test를 구성할 수 있는 개발자 개개인의 역량이 쌓일 것이고, 그런 역량은 개발자로서의 자기만족과 함께 자연스레 더나은(?) 개발자가 될 수 있는 지름길이 될 것입니다.