내가 원하는 test-runner 의 조건

주말에 작성한 google test 용 GUI runner를 오늘까지 4일간 회사에서 사용해봤다. 개밥먹기답게 몇 가지 문제점을 파악할 수 있었고, 내가 원하는 것들이 뭔지도 좀 더 알 수 있게 되었다. 일단  적당히 적어보자면,

Test 가 변화하면 자동으로 샐행되야 한다. 일일이 실행하는건 참 귀찮은 일이다. 기왕이면 JUnitMax 처럼 좀 더 지능적으로 실행 순서까지 골라주면야 좋겠지만..

Test filtering이 되어야 한다. 아주 간단한 형태로 실행할 테스트의 부분집합을 고를 수 있어야 한다. 이건 사실 PyUnit gui runner의 “Enter test name” 의 입력창 값을 가져다가 gtest_filter 에만 넘겨줘도 될듯함. 적당히 집어넣고 돌려본걸론 잘 돌긴하네…

Pre-run hook이 있어야 한다. Unit-test 만 있는게 아니라 functional-test 가 거의 존재해서, 프로그램 코드에서 초기화하기 힘들거나/번잡한 작업을 수행하는 일부 스크립트를 테스트 케이스 실행 전에 돌릴 수 있으면 좋겠다. MSBuild 로 전체 테스트 돌릴 때는 테스트 DB를 리셋하거나 하는 일을 하는데, 지금은 그렇지 못해서 깨지는 테스트들이 있다. Orz

실행 시간의 역순으로 실행하는 기능이 있으면 좋겠다. 일부 테스트는 수행 시간이 꽤 길다. 수 초 수준? 짧은 테스트를 먼저 실행하면 좋을 것 같다. 이건 희망사항?

개밥먹기였지만 맘에 드는걸 쓰자면, 수 초(사용할 때는 10초로 했음) 마다 실행 파일 군을 뒤져서 테스트 결과물(XML 출력물)보다 실행 파일이 새 것이면 실행하게 해놨더니, 내가 빌드할 때마다 적절히 실행되는 것은 맘에 들더라.

사실 이것 때문에 몇 가지 python exception 을 처리해야하긴 했지만… 1 여튼 나름대로 시간대비 잘 써먹는 툴이 되었다. 다만 지금 큰 문제 중 하나가 abort() 같은 걸로 죽을 때 status code 처리가 잘 안되고 있는데 Orz. 이건 최종적으로 test-suite 단위로 실행하지 말고 test-case 단위로 실행하게 해서 fail-fast 하고 좀 더 specific하게 만들어놔야 할듯.

그렇지만 이미 만들어진 GUI runner가 있다. 그냥 VisualStudio 에 붙여서 쓰는 용도라면, 쑥갓 님의 VUTPP2를 쓰는게 더 나은 듯 하다. 다만 내가 원한건 좀 더 비침습적이고, 초기에 설정이 없는걸 원해서여서, 그냥저냥 만들어놓곤 요긴하게 쓰긴하고  있다. 일단 이번 주말까지 – 혹은 그 다음 주말까지 – 좀 더 수정하고, 공개…해야겠다.


  1. 맨 처음 겪은 예외는 이렇다. VisualStudio가 실행 파일을 만들려고 링크하는 단계에서는 해당 결과물을 exclusive-lock을 걸어 버린다. 그래서 mtime 을 얻어오는 gui-runner가 맛이 가더라. 그래서 1초씩 쉬면서 계속 폴링하게 했다… ↩︎

  2. 처음에는 UnitTest++ 용 애드인이어서 이름이 저렇다. 현재는 UnitTest++, google test, boost::test 등 몇 가지 C++ testframework을 지원하고 있다. ↩︎