Unit Testing을 지원하면서 직접 만든 간단한 Unit Testing Framework을 이용하고 있습니다. UT_CHECK_XXX 라는 이름으로 Assertion API를 만들어서 제공하는데, 현재는 CHECK_TRUE(), CHECK_INT(), CHECK_STRING() 정도가 전부입니다. 필요가 생기면 그때 추가한다는 생각에서 간단하게 이 정도만 제공했습니다. (많으면 설명할 것도 많아지니까요. ^^)
최근에 추가한 CHECK가 있어서 소개합니다. filepath로 지정된 외부 텍스트파일을 읽어서 sut_function을 호출하여 결과를 확인해주는 CHECK입니다. 아직 얼마나 효용성이 있을지는 모르겠습니다.
Unit Testing Framework을 살펴볼 때는 다음의 요소들을 살펴보면 됩니다. 빠진 것이 있을지도 모르겠습니다만, 가장 뼈대를 이루는 내용들이라 생각됩니다.
예를들어 CUnit의 경우에는 다음과 같습니다.
Fixture, Shared Setup/Teardown code, Auto-registration 등은 확장된 내용이라고 생각합니다. 필요에 따라 Unit Testing Framework을 직접 만드신다면 기본 뼈대를 놓고 원하는 옵션을 추가해넣으시면 됩니다.
2006년 처음 교육을 하면서 짧게나마 C로 하는 TDD를 다룬적이 있습니다. CuTest를 사용했는데 당장 데모를 위해서는 적절한 선택이었다고 봅니다. 리플렉션이 안되는 단점을 빌드 중에 스크립트를 돌려 Test함수를 모으는 형태로 보완한 것이었는데, 당시로서는 참신하게 생각되었습니다. 지금은 이러한 아이디어가 정말로 실용적일지 잘 모르겠네요.
2007년 C++로 개발하는 팀이 있어 교육과 함께 Unit Testing을 지원할 때는 UnitTest++를 사용했습니다. 역시 간결하고 C++의 기능을 살려 테스트케이스 자동등록(반자동?)이 가능하단 점도 매력적이었죠. C++를 완전히 지원하지 않는 환경이었기 때문에 표준라이브러리를 사용하는 코드와 예외처리 관련 코드를 제거하는 노력이 필요하긴 했습니다만, 그럭저럭 사용에 불편함은 없었습니다.
2008년 C로 개발하는 팀을 지원하면서는 직접 간단한 프레임웍을 만들어서 사용하고 있습니다. 필요에 따라 기능을 추가하거나 좀더 풍부한 기능을 가진 다른 프레임웍으로 교체할 계획이입니다만 아직은 충분한 것 같습니다.
이미 공개되어 있는 다른 프레임웍을 사용하지 않고 굳이 직접 만든 프레임웍을 사용하는 이유가 무엇일까요?
처음에는 가급적 개발자들이 편하게 쓸 수 있는 자동처리 기능을 중시했습니다. JUnit만큼은 아니더라도 비슷하게나마 흉내를 낼 수 있어야겠구나 싶었죠. 하지만 전달한 사람이 잘못한 탓인지 오히려 역기능이 있었습니다. 자동처리되는 부분이 오히려 받아들이는데 장애가 되더군요. 간단히 사용법만 익히면 사용할 수 있겠지 싶었는데 어떻게 동작하는지 모른체로 그냥 넘어가기 쉽지 않은 모양이었습니다. 혹시 임베디드 분야 개발자의 특성은 아닐까 생각되기도 합니다.
우선은 테스트 코드를 왜 작성하는지 어떻게 작성하는지 등이 더 중요한 이슈라고 생각되어 그러한 부분에 집중할 수 있도록 프레임웍과 관련하여 이해해야 하는 내용을 최소화할 필요가 있었습니다. (아이러니죠?) 그렇게해서 테스트 코드를 더 많이 작성하다보면 필요에 따라 필요한 만큼만 자동화하는 식으로 나아가면 되겠죠.
여전히 프레임웍을 찾으시는 분들이 계십니다. JUnit을 접해보신 분들은 더더욱 C/C++ 개발에도 더 편하고 기능이 풍부한 프레임웍이 없느냐고 물어보십니다. 프레임웍을 잘 고르면 노력을 많이 줄일 수 있을 것 같기 때문입니다. 우선 여러가지 추천해드리기는 하지만, 그렇게 프레임웍을 고르고 설정을 맞추는데 시간을 허비하느니 우선 간단하게라도 직접 만들어서 시작하는 것이 어떤가 하는 것이 제 견해입니다.
얼마나 단순한지 한번 보실래요?
(more…)