2012. 1. 5. 09:22
IT
용도 : ibatis sql coverage 측정
라이센스 : 미정
제작사 : NHN
관련자료 : http://helloworld.naver.com/helloworld/1255
문서로는 The Platform 2011 PDF 안에서도 확인이 가능합니다. http://helloworld.naver.com/helloworld/2675
특징 : 테스트 실행후 ibatis xml 파일의 sql에 대한 라인 커버리지 제공
작년동안 SQL Code Inspection을 고민해서 부족하게나마 구현하여 몇번 프로젝트에 적용해보았습니다.
물론 상용 검사도구에서도 충분히 기능을 제공할 수 있는 수준의 것들이라 더이상 진행은 되지 않았지만, SQL에 대해 고민하고 어떤 코드가 좋은 코드일까 고민하도록 해주는 좋은 기회였습니다. (groovy 언어를 즐기는 기회가 되기도 했습니다. )
그런데 비슷한 시기에 SQL에 대한 또다른 유용한 접근이 있었음을 이제야 알게 되었네요.
테스트에서 측정은 중요한 고려사항입니다.
테스트를 했는지 안했는지 알아야 결과를 해석도 할 수 있을테고, 의미가 있는지 없는지도 판단할 수 있을테니까요.
DBMS의 테스트 커버리지 대상을 두 가지 영역으로 나누어 보면 다음과 같습니다.
- TABLE 영역 : TABLE에 대한 C/R/U/D 유무 여부
목적 : 미사용 TABLE 또는 CRUD Matrix 매핑이 안된 경우, 테스트 수행 여부를 확인
방법 : SQL 로그를 통한 분석 또는 DBMS가 제공하는 View를 이용하여 확인가능
비고 : 영향도 분석과 같은 정적분석 방법으로도 사전에 파악이 가능
- SQL 영역 : 프로그램에서 작성된 SQL 실행 여부
목적 : 작성된 SQL의 사용여부 및 테스트 여부를 확인
방법 :
1) 소스 코드내에 SQL이 있는 경우
각 소스 언어별로 제공하는 coverage 툴을 통해서 수행여부를 확인할 수 있습니다.
단 소스와 SQL이 섞여있는 형태이므로 둘을 나누어 식별하기에는 어려움이 있습니다.
2) ibatis와 같이 개발언어와 독립적인 외부 파일로 추출된 형태의 경우
SQL 주석에 식별자를 제공하고 log 또는 DBMS가 제공하는 기능을 이용하여 확인하는 방식을 선택할 수 있습니다. ( Coverage4iBatis의 경우에는 SQL 주석안에 CoverageID 를 부여하고 로그에서 실행 여부를 확인하고 있습니다. ) cf) ibatis가 제공하는 id를 사용하지 않고 별도의 id를 부여한 것은 나름의 이유가 있었겠죠?
비고 : 고유 ID 내에서도 동적으로 나누어지는 경우를 어떻게 처리했을까 하는 부분은 흥미롭습니다.
Coverage4iBatis 블로그 글에서 예로 보여준 동적 SQL의 iterate 문장의 실행 여부를 어떻게 접근했을까요?
Coverage4iBatis는 두번째 영역인 SQL에 대해 테스트가 되었는지를 확인하는 방법을 제공하고자 했습니다. 물론 특정 프레임워크(ibatis)에 한정적인 접근이기는 하지만 숨겨져있던 DBMS 영역에 대해 또다른 테스트의 메스를 들어올린 점은 반가운 일입니다.
주제넘지만 한가지더 NHN의 생산성 혁신랩에 권고드리는 것은 (SQL의 코딩 컨벤션 가이드가 언급되는걸 보면 아마도 이미 제공하고 있을지도 모르겠네요..) SQL 상의 나쁜 냄새에 대한 패턴을 확장하고, 이를 알려주는 도구도 같이 활용하시라는 겁니다. (java의 PMD와 같은 역할을 생각하시면 될거 같네요.)
Coverage4iBatis 블로그 글 말미에 언급하듯이 테스트하기 쉽고, 단순한 SQL을 작성하기 위해 개발자의 노력이 필요합니다.
코드의 복잡도가 "당신의 코드가 정말 그렇게 복잡해도 되냐"고 다시 생각하도록 유도하듯이,
SQL의 나쁜 냄새에 대해서도 "당신은 그 냄새를 맡고있어도 괜찮냐" 고 물어보도록 하는 것이 좋을듯합니다.
피하지 못한다면 즐겨야겠죠.