어제 포스팅에서 불편하단 소릴 하긴했지만, 작년 한 해 동안 작성한 테스트 케이스는 전부 이 녀석으로 작성했고, 지금도 잘 돌아가고 있다. 수 시간 전에 빌드서버에서 실행된 애들도 있을듯…
다음과 같은 인자를 받아서 이를 해석하는데, 방식은 *nix의 getopt와 비슷하다. 즉,
- –help 에 도움말이 나오고
- –long-option or -s 처럼 긴 옵션과 짧은 옵션이 같은 의미를 같게 짝 지어져 있고,
- 대부분의 UNIX 명령어 같은 느낌으로 돈다
여튼 내가 만든 녀석은,
- –suite 혹은 -s 로 실행할 테스트 스윗을 받고 (없으면 몽땅)
- –testcase 혹은 -t 로 실행할 테스트 케이스 이름을 받고 (역시 없으면 몽땅)
- –output 혹은 -o 로 테스트 리포트를 받는다. 이게 없으면 콘솔로 있으면 파일로. 그리고 파일 확장자가 .xml 이면 XML 형태로, 아니면 다시 콘솔로(…) 출력한다.
같이 동작한다. 물론 –help도 있다(…).
구현 코드는 boost::program_options를 써서 좀 뻔하다.
po::options_description desc("Allowed options" ); po::positional_options_description p; p.add("suite", -1); desc.add_options() ("help", "produce help message") ("output,o", po::wvalue<wstring>(&out), "test-report output path") ("suite,s", po::wvalue<wstring>(), "test-suite to run") ("testcase,t", po::wvalue<wstring>(), "test-case to run") ; po::variables_map vm; po::store( po::wcommand_line_parser( argc, argv ).options( desc ).positional(p).run(), vm ); po::notify(vm);
이 간단한 코드가 옵션을 정하고 / 이를 해석하는 코드가 된다. ((덤으로 UTF-16 인코딩된 unicode 기반의 프로그램이라서 wstring을 쓴다 ))
p.add( “suite”, -1 )은 기본 옵션 — 아무런 옵션 이름을 안주고 인자를 주면 그거에 대한 인자를 준걸로 받아들임 — 을 위해 사용한 것이니 신경쓰지 않아도 된다.
전체 코드는 여기에 링크 해 둔다. 이런 형태로 상당히 불편하긴 하지만, UnitTest++ 로 작성된 테스트 케이스들을 실행하는 커맨드라인 프로그램이 만들어진다. 뭐 이런 식으로 *nix 명령어/유틸리티스러운 커맨드라인 프로그램을 작성할 때 써먹어도 된다(사실 이 용도로 매우 잘 써먹고있긴하다).
