Small Steps Blog

예전 포스트에 올린 자료에서 /Profile 옵션을 켜야 VC++의 coverage 분석을 할 수 있다고 하였다. 이 옵션은 Coverage 분석을 위한 필수 옵션이다.

고려할 옵션이 하나 더 있다. /OPT:NOREF 라는 최적화 옵션이다.

링커의 기본 최적화 설정은 따라 참조되지 않는 데이터를 링크할 때 삭제해 버린다. 이렇게되면 Coverage 분석할 때 모두 몇 라인 중에서 몇 라인이 커버되었다라는 분석데이터가 정확하지 않게 된다. 함수 foo() 가 테스트 코드에서 호출되지 않아서 실행파일에 포함되지 않기 때문이다.

/OPT:NOREF 옵션은 참조되지 않는 데이터도 유지하겠다는 옵션이다.

이 옵션을 찾게 된 이유는 새로 테스트를 추가했는데 오히려 Coverage가 낮아진 경우가 있어서였다. Test가 추가되었는데 Coverage가 낮아지다니!.. 하지만 TDD로 개발한 것이 아니다보니  어쩔 수 없는일… 우선은 TAD(Test after development)라도 열심히하고, 다음부턴 TDD 열심히 해야지.

Visual Studio Team System을 이용하면 C/C++ 프로젝트도 코드커버리지를 구할 수 있다.

google을 검색하면 여기저기서 자료를 구할 수 있는데 한글로 정리된 자료가 부족한 듯 하여 팀내위키에 정리된 것을 pdf로 만들어서 올려본다.

CodeCoverageUsingVisualCpp

레거시 코드에 TDD를 적용하는 단기간 TDD적용 프로젝트를 진행하는 중에 참고하는 메트릭이 있다.

• 테스트케이스 개수
• 코드커버리지
• 순환복잡도

순환복잡도의 경우는 리팩터링을 진행하면서 진척되는 느낌을 갖기 위해 추적하게 된다. 그런데 좋은 코드, 깔끔한 코드에 대한 감을 잡기 전에 단지 복잡도만 바라보면서 리팩터링을 하게 되는 경우가 생기곤 한다. 500라인, 1000라인짜리 함수보다야 백번 낫겠지만 의미있는 단위의 함수가 아닌 단지 복잡도만 낮추기 위한 함수 잘라내기에 그치는 경우가 있는 것이다. 그럴때면 누차 강조한다. 읽기 쉽게 만드는 것이 일차적인 목표라고…

코드커버리지는 테스트코드 작성 시 참고할 목적으로 측정한다. 어쨌거나 Exit criteria는 있어야 하니 90%이상을 목표로 하여 진행한다.¹ 그런데 이 경우에는 단지 해당 코드 패스를 통과하기만 하는 테스트가 추가되는 경우가 생기기도 한다. 이런 테스트들은 구현에 지나치게 의존적이면서 테스트로서 가치를 제공하기 보다는 오히려 자유로운 리팩터링을 저해할 수도 있다.

언제나 그렇지만 메트릭은 역기능을 가지고 있음을 염두에 두어야 한다.

참 오늘은 마침 그믐이다. 손가락을 보거나 검은 하늘 바라볼 밖에

1. TDD로 진행하지 않은 레거시 코드의 경우는 사후 Unit test로 70% 정도를 커버했다면 양호한 수준이라 할수 있다. [↩]