Pragmatic Story(실용주의 이야기)

개발하던 도구 릴리즈를 위해 막바지 작업이 한창이었습니다. 테스트를 해보니 결과가 이상해서 몇 번의 디버깅을 통해서 에러를 수정했는데 이 작업을 하면서 느낀점을 정리했습니다.

제가 개발한 도구는 iBatis를 사용할때 작성하는 SQLMap 파일의 코드 커버리지를 측정하는 도구입니다. iBatis를 잘 모르시는 분들을 위해 부연설명합니다. iBatis는 DB의 데이터를 쉽게 처리할수 있도록 지원하는 프레임워크이며 SQLMap파일은 XML파일로서 쿼리문을 담고 있습니다.

동작하는 순서는 대충 이렇습니다.

Step1: 쿼리문 실행로그를 남기기위해 SQLMap 파일을 변조합니다.
Step2: 테스트 코드를 이용해 테스트를 실행합니다. Step1에 의해 실행로그가 쿼리ID별로 남습니다.
Step3: 로그를 이용해서 커버리지를 측정합니다.

허드슨(Hudson)을 이용해서 실행 했더니 아래와 같은 이상한 결과가 나왔습니다. 54번째 라인만 커버가 안된것으로 나온겁니다. <select>엘리먼트 단위로 검사하기 때문에 </select>는 기본적으로 포함되는 영역이니 버그입니다.

이 버그를 찾기위해서 어떻게 접근해야 할까를 고민했습니다. 이 도구가 Maven 플러그인이라 제대로 테스트를 하려면 다시 빌드해서 허드슨에 올려서 Job을 실행해야 정확한 결과를 확인할 수 있습니다. 환경이 달라서 로컬에서 실행하는 Test Case로는 정확한 재현이 어려웠습니다. 제가 접근한 방법은 이렇습니다.

1.해당 테스트가 실행되었을때 로그를 수집한다.
2.그 로그가 만들어진 소스파일(이 경우에는 SQLMap.xml)을 수집한다.
3.로그 + 소스를 이용해 만들어지는 커버리지 측정파일을 수집한다.

이 3개 파일로 Mock 테스트를 로컬에서 만들었습니다. 로컬에 오류 재현을 위한 Test Harness를 구축한 것으로 보시면 됩니다. 이렇게 하니 굳히 서버에 배포를 하지 않아도 에러를 재현할 수 있었습니다.

먼저 로그파일을 읽어들여서 결과가 정확히 나오는지 확인하는 TC를 추가했습니다.

성공하더군요. 음 로그는 문제가 아니었습니다. 그래서 두번째로 커버리지 측정 부분에 대한 TC를 추가했습니다.

이 TC를 이용해서 이클립스의 디버깅 모드로 한단계 한단계 추적해 들어가봤습니다. 전 이럴때 이클립스가 정말 좋은 도구라고 느낍니다. 디버깅이 스포츠 중계로 바뀌는 순간입니다. 몇 번의 시행착오를 거쳐서 문제가 되는 코드의 주요 부분을 찾을 수 있었고 분기되는 코드에 브레이크 포인트를 걸어서 쉽게 에러를 찾을 수 있었습니다.

제가 여기까지 오는데 걸린 시간은 2시간 남짓이었고 결국 에러를 찾을 수 있었습니다. SQLMap이 지원하는 특정 엘리먼트 하나를 빼먹는 바람에 생긴 버그였습니다. 뭐 수정은 30초도 안걸렸던거 같네요.

코딩에 걸리는 시간보다 디버깅에 걸리는 시간이 훨씬 많다는 이야기를 많이 합니다. 디버깅을 잘하고 싶으신가요? 그럼 버그를 재현할 수 있는 테스트 환경을 정확히 구축하세요. 에러가 보일겁니다.

Debug It! 실용주의 디버깅에 보면 버그 재현을 위해 할일을 세가지로 구분했습니다.

• 소프트웨어 그 자체
• 실행환경
• 입력값

기억에 두시면 디버깅에 도움이 됩니다.