개발프로젝트의 경험공유 : TestCase의 문제와 TestCase만으로 해결 할 수 없는 문제에 대한 풀이의 고안.

개발프로젝트의 경험공유
TestCase의 문제와 TestCase만으로 해결 할 수 없는 문제에 대한 풀이의 고안.

이번 프로젝트로 테스트팀이 개발팀 외부에 있을 경우에 품질에 대한 확신이 높아지는 것을 확인했습니다.
전체적인 진행에 대해서는 따로 포스트 하려고 합니다만, 여기서는 우선, 개인적으로 이번 프로젝트에서 얻은 성과를 공유하고자 합니다.

개인적으로는 이번 프로젝트에서 느낀 것은,
1) perl의 경우, 프로그램을 종료하지 않는, 대화식의 interactive한 테스트용 프로그램을 만들기가 훨씬 더 쉬웠으며
2) eval이 지원된다면 모듈을 hot deploy도 할 수 있고, 직접적인 함수의 사용 결과를 눈으로 볼 수도 있어 유연한 테스트를 할 수 있었습니다.

우선은 TestCase를 사용했습니다.

처음에는 제가 작성하는 Module의 함수의 테스트를, Perl에서의 Test Framework이라고 말 할 수 있는 Test::More를 통해서 했습니다.
이 테스트를 통과하면 업로드 했습니다. 처음에는 괜찮았는데, 나중에 가니 테스트프로그램의 훨씬 더 커졌버리더군요.

하나의 함수를 사용할 수 있는 경우가 여럿인 경우, 모두 통과하게 해야 했으니까요.
예를 들면, select, insert, update, delete하는 DAO형식의 함수 4개를 만들었다고 할 때,
테스트 해야하는 항목으로는, 각 DAO의 함수에 대해 Parameter가 null일때, Parameter의 type이 잘 못되었을 때, Parameter의 조건이 안맞을 때
또, Data가 이미 있는데 insert하려 할 때, 없는데 update하려 할 때, 등등으로 4개함수당 테스트 해야할 케이스가 평균 50여개 정도가 나왔습니다.

이번 프로젝트에서는 외부로 공개해야하는 함수(perl에서는 subroutine)은 182개, 내부적으로 사용하는 것까지 합하면 작성한 함수는 약 220여개 정도가 되었습니다.
물론 만들어 놓고 보니, 납품하는 입장에서도 안심은 되더군요. 그러나 매우 노가다성 작업이라는 것을 알았습니다.
작성이 완료되었는데, 인터페이스상, Parameter가 하나 늘거나 또는 줄거나 하면(물론 parameter의 hash값의 key/value가 늘거나 줄거나 하는 것입니다.),
모듈만 수정하는 것보다, 테스트를 수정하는 것이 큰 일이었습니다.

TestCase만으로는 해결할 수 없는 문제.

문제는 또 있었습니다.
함수의 동작에는 문제가 없는데, 이를 사용해 조합하는 부분에서 잘 못 사용해서, 로그에는 제가 작성한 함수의 부분에서 출력하는 문자열이 남아서, 저에게 Bug Assign되는 것이었습니다.
조합하는 부분의 담당 개발자에게 api 인터페이스 문서를 보고 고치라고 강요할 수도 있지만,
결국은, 조합하는 부분의 코드를 어떻게 작성했는 지, 직접 열어보고야 말았습니다. (여기서 기가막혔습니다. perl 1만줄!)

이때는 실전에서 전달되는 값에 대한 테스트는 Test case로는 할 수 없습니다.
보통 이때의 디버깅 방법은
(1)console이나 파일로 값을 출력하게 하는 부분을 넣고, 다시 돌려보는 것이 일반적입니다.
(2)좀 더 똑똑하게 로그 파일로 출력하게 하는 경우도 있습니다. (그러나 웹과 같이 그 뒤에 요청되는 다른 request를 처리하는 로그가 계속 쌓이면 찾아보기 어렵습니다.)
(3)그보다 좀 더 수준높게 Debugger를 돌려 Trace하는 방법이 있습니다. 어쩌면 Perl에서 사용하기 쉬운 Debugger가 있었다면 이를 사용했을 지도 모릅니다.

우선, 조합하는 부분의 소스는 제가 직접 손 대는 것이 적합하지 않았습니다. 왜냐하면 계속 작업중이었기 때문이죠.
복사해서 로컬에서 수정해 볼 수는 있지만, 실전 DB의 값을 사용해 돌리게 하면, 시스템이 이상해 질 수도 있는 문제였습니다.
그렇다고 테스트 DB만 있으면 해결 할 수 있는 것도 아니었습니다. 가상머신을 생성하는 등, system call하는 부분이 많기 때문에, 적합한 환경이 제공되지 않으면, 기동하는 것도 불가능했습니다.

그래서 저는 이번에는 조그만 interactive한 프로그램(while(true)문으로 입력을 기다리고, 받아서 처리하고 다시 입력을 기다리고.. 하는 프로그램입니다.)을 만들어서, 현재의 실전 환경에서 이러한 값을 넣었을 경우, 함수가 어떻게 동작하는지 알아보는 방법을 취했습니다.
그리고 실전환경과 같은 함수에 데이타를 넣어보기 위해, 실행할 문장을 입력받아 실행하도록 eval을 사용했습니다.
이 방법은 매우 유연한 입력을 받을 수 있어서 테스트 하기에 아주 적합하다는 것을 알았습니다.

이번 경험의 확장

interactive한 프로그램은 perl로만 가능한 것이 아니라 어떤 언어든 가능합니다만,
eval은 그렇지 않습니다. eval은 주로 scripting언어에만 존재합니다.
compile언어에서는 실시간으로 해석하지 않고 컴파일된 코드를 수행하는 것이기 때문에 scripting언어보다 더 나은 퍼포먼스를 보이는 것이니까요.
그런데, java에서는 eval은 없지만, groovy에서 Eval 클래스가 있는 것을 알았습니다.
또 class의 핫디플로이라면 classloader의 loadClassData()를 직접 호출해서 hot deploy를 구현하면 될 것 같습니다.

그리고 닷넷 4.0에서는 Scripting을 지원한다고 하는데 어떻게 지원되는 지 아직 살펴보고 있지 않습니다.
c/c++에서는 아무래도 어렵지 않을까 싶습니다. (perl에서 inline c를 사용하는 방법으로 응용할 수 있을지. 어떨까 싶습니다.)


이러한 경험이, 다른 개발을 담당하시는 분들께 도움이 되었으면 하고, 정보공유합니다.

아직 개발이 완료된 것은 아닙니다. 좀 작업은 남아 있습니다.
좀 더 다른 느낀 점이 있다면 공유하겠습니다.

그리고...

저는, 개발경험 이외의 것이 더 큰 수확입니다. (다음번 포스트에서 적어볼가 합니다.)
개발경험도 개발경험이지만, 개발은 다른 사람에게 맡기고,
전체적으로 프로젝트를 지휘하는 것이 훨씬 재미있겠다라는 생각이 들었습니다.

이상.
정보공유 끝.