Blog

여러 칼럼에서와 마찬가지로 6월에도 지난 칼럼 내용부터 간단히 복습해보자. 무엇을 얼만큼 배웠는지, 잊지 말고 기억해둬야 할 점은 무엇인지 다시 머리 속에 각인시켜보자.

3월부터 3개월에 걸쳐 ‘지속적인 컴파일’이란 제목을 달고, 오픈 소스 빌드 서버인 CruiseControl .NET(CCNET)을 설치하고, 버전 관리 시스템인 서브버전과 CruiseControl .NET을 연동했으며, 빌드 서버를 통해 비주얼 스튜디오 솔루션(.sln)을 빌드해봤다.

특히 지난번엔 비주얼 스튜디오 솔루션을 CruiseControl .NET과 연동해 빌드하는 법을 알아봤는데, 실수하기 쉬운 부분이 있었다. CruiseControl .NET 문서에 ‘Visual Studio Task’란 항목이 있다고 해서 ‘아 이건가 보다’하면 안 된다. 이 태스크는 비주얼 스튜디오의 바이너리 파일을 직접 호출해서 프로젝트와 솔루션을 컴파일하는데, 그 때문에 확장성이 떨어진다. 비주얼 스튜디오가 제공하는 빌드 전 이벤트, 빌드 후 이벤트, 빌드 기능은 쓸 수 있지만, 빌드 전에 테스트용 데이터베이스를 만든다던가, 레지스트리를 조작한다던가 하는 수준 높은 기능은 제공하지 않는다. [목록 1]은 CruiseControl .NET 문서의 예제인데, 고작해야 세 가지 빌드 유형(Build, Rebuild, Clean)과 설정(Debug, Release) 정도만 설정할 수 있을 뿐이다.

[목록 1] Visual Studio Task

<devenv>
    <solutionfile>src\MyProject.sln</solutionfile>
    <configuration>Debug</configuration>
    <buildtype>Build</buildtype>
    <project>MyProject</project>
    <executable>c:\program files\Microsoft Visual Studio .NET\Common7\IDE\devenv.com</executable>
    <buildTimeoutSeconds>600</buildTimeoutSeconds>
    <version>VS2002</version>
</devenv>
			

이런 기능상의 한계 때문에 우리는 MSBuild Task를 쓰기로 했다. MSBuild는 자바용 Ant와 마찬가지로 빌드 전용으로 만들어진 XML 기반 스크립트 언어이다. MSBuild 같은 빌드 스크립트 도구만 있으면 데이터베이스를 만들거나 레지스트리를 조작하거나 동적으로 설정 파일을 만드는 것쯤은 누워서 떡 먹기나 다름없다. 실제로 어떤 일을 할 수 있는지는 목록 2를 훑어보면 대강 파악할 수 있다. 또한 MSBuild는 SDK를 제공하므로 확장기능을 직접 제작해 MSBuild가 직접 제공하지 않는 기능도 만들어낼 수 있다.

[목록 2] MSBuild의 주요 기능

• AspNetCompiler 작업

• Copy 작업

• Csc 작업

• Delete 작업

• MakeDir 작업

• WriteLinesToFile 작업

대안이 될만한 빌드 스크립트인 NAnt 등이 있긴 하지만, 업데이트 등이 문제가 되어 MSBuild를 쓴다

VC++을 위한 단위 테스트

지속적인 컴파일을 세 번에 걸쳐 다뤘지만, 실은 겉핥기에 불과하다. 컴파일이라고 해도 여러 조건이 있다. C# 프로젝트, C++ 프로젝트, C++/CLI 프로젝트 등은 그 나름대로 특징이 있고, 주의해야 할 점도 다르다. 또한 프로젝트 규모가 크거나 C#, C++, C++/CLI 등 다양한 프로그래밍 환경을 함께 쓰는 경우엔 더더욱 주의할 사항이 많다. 하지만 그렇다고 몇 달씩 컴파일만 죽어라 파고들면 지루해지기 쉬우니 이번엔 단위 테스트에 대해 알아보자. 좀더 복잡한 컴파일 방법에 대해선 차근차근 알아보면 된다.

다양한 단위 테스트 도구

C++ 환경은 닷넷이나 자바 환경과 달리 단위 테스트가 널리 퍼지지 않았다. 여러 이유가 있지만, 아무래도 자동화하기가 힘든 면이 많고, 그래서 다른 환경만큼 단위 테스트 도구가 편리하지 않기 때문인 탓이 크지 않나 싶다. 그럼에도 불구하고 C++ 개발자들은 굴하지 않고 좀더 나은 소프트웨어를 만들고자 꾸준히 노력해왔다. 그런 선구자들 덕분에 우리에겐 꽤 많은 선택권이 주어졌다. 어떤 도구들이 존재하는지 목록 3을 한번 살펴보자.

[목록 3] 윈도우에서 사용 가능한 C++용 단위 테스트 도구

• Boost Test Library

• C Unit Test System

• cfix

• CppTest

• CppUnit

• CxxTest

• RCUnit

• UnitTest

• UnitTest++

• 등등

목록이 너무 길어서 임의로 몇 개만 간추려 적었다. 실은 opensourcetesting.org 가 제공하는 목록도 완벽한 건 아니라서, NanoCppUnit, WinUnit 등 헤아리기 어려울 정도로 많다. 무료로 마음껏 쓸 수 있는 테스트 도구만 나열해도 이 정도다!

좋은 단위 테스트 프레임워크의 조건

자, 단위 테스트 도구가 가득한 백화점에 들어서긴 했는데 도대체 무엇을 골라야 할까? 어떤 도구를 골라야 잘 골랐다는 소문이 날까? 프로젝트가 서너 달 이상 진행된 이후에 ‘아뿔싸! 이런 문제가 있었다니!’라며 땅을 치고 후회하지 않을 그런 도구는 어떤 걸까?

Noel Llopis가 쓴 ‘C++ 단위 테스트 프레임워크 정글을 탐험하기’(Exploring the C++ Unit Testing Framework Jungle)란 글은 단위 테스트 도구를 선택할 때 고려해야 할 조건들을 잘 정리해놨다. 한번 글의 내용을 간략히 살펴보자.

1. 새 테스트를 추가할 때 최소한의 노력만 들어야 한다.

   키보드를 눌렀다 뗄 때의 그 느낌을 좋아한다. 누른 힘만큼 되돌려주는 그 감각이 즐겁다. 하지만 그것도 손가락이 피곤해지면 슬슬 지겨워진다. 하루 8시간 이상을 컴퓨터 앞에서 보내는 전문 개발자라면 언젠가 키보드와 마우스가 지겨워질 때가 오기 마련인데, 그런 만큼 이것이야말로 가장 중요한 기준이 된다.

2. 변경하기 쉽고 이전(마이그레이션)하기 쉬어야 한다.

   누구나 수긍할 조건이지만, 때로는 이런 조건은 양보해도 된다. 게임의 경우 대부분 윈도우 환경에서만 개발하기 때문에 ‘이전’이란 부분은 그리 중요하지 않을지 모른다. 프로젝트 성격에 따라 적절히 판단하면 된다.

3. Setup/Teardown 기능을 지원해야 한다.

   Setup과 Teardown은 각각 단위 테스트를 시작하고 끝낼 때 공통적으로 수행되는 함수를 말한다. 단위 테스트 코드는 유독 중복이 발생하기 쉬운 까닭에 DRY(Don’t Repeat Yourself, 반복하지 말라) 원칙을 지키기 어렵다. 하지만 Setup/Teardown 기능이 있으면 좀더 상황을 호전시킬 수 있다.

4. 예외(exception)와 충돌(crash)을 잘 다뤄야 한다.

   테스트 대상인 코드에서 예외나 충돌이 났다고, 테스트 프레임워크까지 죽어버리면 곤란하다.

5. 어썰트 기능이 좋아야 한다.

   다양한 어썰트 기능이 있으면 좋다. LessThen, MoreThan 같이 인간 친화적인 어썰트가 있으면 가독성까지 높일 수 있다.

6. 다양한 출력을 제공해야 한다.

   테스트 실행 결과를 출력하는 방식으론 크게 세 가지가 있다. GUI, 콘솔, 그리고 파일이다. GUI를 통해 화려하게 출력해준다면 개발자들의 흥미를 끌기 좋지만, 정작 쓰기엔 콘솔이 빠르고 편리한 경우가 많다. 빌드 자동화를 할 때는 파일로 출력해야 하는데, XML 포맷이 지원되어야 CruiseControl .NET 같은 도구와 연동하기 좋다.

   요약하자면 콘솔과 XML 파일 출력은 지원해야 한다.

7. 수트(Suite)를 지원해야 한다.

   수트는 테스트를 여러 범주로 나누는 기능이라 생각하면 된다. 수트는 그리 중요한 요구사항은 아닌데, 수트 기능이 없어도 테스트의 명명 규칙만 세우고 잘 지키면 되기 때문이다.

단위 테스트 프레임워크 고르기

VC++ 환경용 단위 테스트 도구로는 뭐가 있는지 알아봤고, 어떤 걸 골라야 하는지 그 기준에 대해서도 알아봤다. 이제 이러한 기준을 잣대로 주요 후보를 검토해보고 하나 골라보자. 수십 개의 후보를 모두 검토해볼 수는 없으니 이 중 몇 개를 골랐는데, 대중적 인기에 따라 임의로 골라보면 다음과 같다.

• CppUnit

• Boost Test Library

• UnitTest++

CppUnit

아마도 C++ 세계에서 가장 유명하고 사용자도 많은 테스트 프레임워크가 아닐까 싶다. 내가 가장 처음 접한 단위 테스트 프레임워크 중 하나이기도 하고, 한국어 검색을 하면 자료가 많이 나오기도 한다. 하지만 단위 테스트를 해본 적이 없던 사람에겐 이 라이브러리는 조금 벅찼다. 무엇보다 테스트 하나를 만들려고 하면 노력이 너무 많이 들었다. Noel Llopis가 작성한 예제 코드를 또 다른 테스트 라이브러리인 UnitTest++ 코드와 비교해보자.

[목록 4] CppUnit 예제

#include <cppunit/extensions/HelperMacros.h>

class SimplestCase : public CPPUNIT_NS::TestFixture
{
  CPPUNIT_TEST_SUITE( SimplestCase );
  CPPUNIT_TEST( MyTest );
  CPPUNIT_TEST_SUITE_END();

protected:
  void MyTest();
};

CPPUNIT_TEST_SUITE_REGISTRATION( SimplestCase );

void SimplestCase::MyTest()
{
    float fnum = 2.00001f;
    CPPUNIT_ASSERT_DOUBLES_EQUAL( fnum, 2.0f, 0.0005 );
}
			

[목록 5] UnitTest++ 예제

#include <UnitTest++.h>

SUITE(SimplestCase)
{
	TEST(MyTest)
	{
		float fnum = 2.00001f;
		CHECK_CLOSE( fnum, 2.0f, 0.0005 );
	}
}
			

얼핏 보기에도 그 차이가 크다. 이외의 나머지 6가지 기준으로 보면 CppUnit은 상당히 훌륭하다. 리눅스와 윈도우 양쪽에서 잘 작동하고, 예외 처리도 잘 되고, 어썰트 종류도 많으며, 출력 양식도 다양하다. 하지만 역시 코드량이 많아진다는 점은 부담이 된다.

불과 몇 년 전만 해도 CppUnit의 대안이 거의 없었다고 기억한다. 그래서 선택권이 거의 없었다. 하지만 지금은 대안이 많고, 더 좋은 기회를 찾기 쉽다. 그래서 CppUnit은 대상에서 제외한다. 물론 프로젝트 성격이나 개발자의 취향에 CppUnit이 잘 맞는다면 반대할 이유는 없다.

Boost Test Library

부스트 라이브러리의 일부로써 배포되는 테스트 라이브러리다. 홈페이지에 가서 목차를 읽다보면 “The minimal testing facility”란 문구가 눈에 띄는데, 말 그대로 Boost Test Library는 최소한의 기능을 제공한다는 철학을 갖고 있다. 그래서 작은 프로젝트엔 적합하지만, 다양한 시도를 해야 하는 프로젝트엔 적합하지 않다. Noel Llopis가 이것을 가장 잘 보여줬다고 생각하는데, 앞서 제시한 단위 테스트 코드의 Boost Test Library 버전을 살펴보자.

[목록 6] Boost Test Library 예제 – 수트 없이

#include <boost/test/auto_unit_test.hpp>
#include <boost/test/floating_point_comparison.hpp>

BOOST_AUTO_UNIT_TEST (MyFirstTest)
{
    float fnum = 2.00001f;
    BOOST_CHECK_CLOSE(fnum, 2.f, 1e-3);
}
			

보다시피 UnitTest++만큼 간단하다. 겉보기엔 UnitTest++의 코드가 더 길지만, 목록 5에선 수트를 지원했으니 실은 코드 길이는 똑 같은 셈이다. 하지만 이토록 간단했던 코드에 수트 기능을 넣으려 하면 재앙이 벌어진다.

[목록7] Boost Test Library 예제 – 수트 지원

#include <boost/test/unit_test.hpp>
#include <boost/test/floating_point_comparison.hpp>
using boost::unit_test::test_suite;

struct MyTest
{
    void TestCase1()
    {
    	float fnum = 2.00001f;
        BOOST_CHECK_CLOSE(fnum, 2.f, 1e-3);
    }

    void TestCase2()
    {
    }
};

test_suite * GetSuite1()
{
    test_suite * suite  = BOOST_TEST_SUITE("my_test_suite");

    boost::shared_ptr instance( new MyTest() );
    suite->add (BOOST_CLASS_TEST_CASE( &MyTest::TestCase1, instance ));
    suite->add (BOOST_CLASS_TEST_CASE( &MyTest::TestCase2, instance ));

    return suite;
}

#include <boost/test/auto_unit_test.hpp>
using boost::unit_test::test_suite;
extern test_suite * GetSuite1();

boost::unit_test::test_suite*
init_unit_test_suite( int /* argc */, char* /* argv */ [] ) {
    test_suite * test = BOOST_TEST_SUITE("Master test suite");
    test->add( boost::unit_test::ut_detail::auto_unit_test_suite() );
    test->add(GetSuite1());
    return test;
}
			

휴, 코드를 해석해보려다 그냥 포기했다. 뭐가 이렇게 복잡한지.

이 외에도 Boost Test Library는 미흡한 점이 많은데, 무엇보다 치명적인 건 다양한 출력 포맷을 지원하지 않는다는 점이다. CruiseControl .NET과 연동하려면 XML 파일 형태로 테스트 결과를 뽑아줘야 하는데, 이런 기능이 미흡하다.

UnitTest++

결론부터 말해 우리는 UnitTest++을 쓴다. 앞서 언급한 Noel Llopis가 쓴 글에선 UnitTest++이 언급되지 않지만, 실은 그도 최종적으론 이 테스트 라이브러리를 선택했다. 그가 쓴 테스트 주도 개발: 무엇을 왜? 어떻게?라는 프리젠테이션 자료를 박일씨가 번역해놨는데, 이 자료의 예제 코드는 모두 UnitTest++ 기반이다.

[목록 5]에서 봤듯 UnitTest++로 짠 테스트 코드는 간결하다. 윈도우와 리눅스, 그리고 Mac OS X을 지원해서 이식성도 좋다. 수트 기능을 지원하고 Fixture 기능을 통해 Setup/Teardown를 할 수 있다. XML 파일로 출력되므로 CruiseControl .NET과 연동된다는 점도 중요하다.

부족한 점을 찾아보기 힘들면서도 간결한 라이브러리라 좋다. 또한 한국의 게임 개발자들이 선호하는 라이브러리이고, 그 덕분에 VisualUnitTest++이라는 훌륭한 성과물이 나오기도 했다. 이 도구는 비주얼 스튜디오와 UnitTest++을 통합해준다.

앞으로 이어지는 칼럼에선 UnitTest++을 CruiseControl .NET과 연동하는 법에 대해 자세히 알아보겠다.

C#을 위한 단위 테스트

MSTest

C#용 단위 테스트 도구는 여럿 있지만, 그 중에서 고려해볼 것은 두 개이다. 우선 Visual Studio 2005 및 Visual Studio 2008에 함께 딸려오는 MSTest가 있다. “MSTest의 테스트 결과 출력”란 그림을 통해 알 수 있듯 비주얼 스튜디오와의 통합 기능은 엄청난 장점이다. 이런 통합 기능이 있으면 개발자는 엄청나게 편해지지만 이러한 기능을 공짜로 제공하는 도구는 거의 없다. 엄밀히 말해 MSTest의 경우엔 통합 기능에 대한 가치가 Visual Studio 판매가격에 포함된 거라 봐야겠지만, 다른 도구의 경우엔 추가 비용이 지출된다는 점에서 보면 확실한 이점이다.

그림 1. MSTest의 테스트 결과 출력

MSTest는 경쟁 프레임워크에 비해 역사가 짧다. 그래서 변화를 많이 겪는 시점이라 하겠는데, Visual Studio 2008로 넘어오면서 많은 게 바뀌었다. 특히 빌드 자동화를 꾀하는 입장에선 MSTest이 XML 출력 양식이 바뀐 게 가장 큰 문제다. 현 시점의 CruiseControl .NET은 MSTest 2005를 지원한다. 만약 여러분이 Visual Studio 2008을 쓴다면 문제가 되겠지만, 다행히 해결책이 있다. Alex Hutton이란 고마운 사람이 VS2008을 연동할 때 필요한 XSL 파일을 만들었다.

XSL 파일은 CruiseControl .NET 대시보드를 통해 테스트 결과를 보여줄 때 필요하다. 하지만 빌드 자동화를 하려면 더 많은 걸 알아야 한다. 다음 두 문서가 도움이 될 것이다.

• MSTest and CruiseControl .NET

  가장 간단한 방법을 소개하는데, CruiseControl .NET의 힘을 빌려 MSTest를 실행한다.

• Running MSTest against .NET 2.0 on CruiseControl.NET

  좀더 복잡하지만 몇 가지 미묘한 문제를 해결할 수 있는 방법을 소개하는데, MSBuild의 힘을 빌려 MSTest를 실행한다.

굳이 이렇게 관련 정보를 직접 설명하지 않고 링크만 알려주는 이유가 있다. 앞으론 MSTest에 대해 더 다루지 않을 것이기 때문이다. 그 이유는 아주 간단하다. MSTest가 x64 단위 테스트를 지원하지 않기 때문이다. 게임용 서버 애플리케이션을 개발하는 입장이다 보니 64비트 개발 환경을 지원하는 도구밖에 쓰지 못한다. 그래서 이 문제를 발견하곤 전에 쓰던 NUnit을 다시 쓰게 됐다. 물론 여러분이 32비트 환경에서만 개발을 한다면 MSTest는 좋은 선택이 된다. 무엇보다 별도의 비용 지출 없이 비주얼 스튜디오와 긴밀하게 통합되는 도구를 손에 넣으니 이보다 좋을 수가 있겠는가? 어쨌든 이 칼럼에선 x64 환경을 함께 다루기 때문에 MSTest는 후보에서 제외한다.

일화

빌드 자동화를 꾀하다 보면 막힐 때가 많다. 그럴 땐 열심히 구글링을 해서 문제를 해결하면 되지만, 어떤 검색어로 찾아야 할지 모를 때도 있고, 제대로 검색어를 고른 듯 한데 원하는 결과가 나오지 않을 때도 있다. 몇 시간씩 고생하고도 해결책을 못 찾으면 참 답답하다. 짜증이 치밀고 때려치우고 싶을 때도 있다.

이럴 때는 정말 일을 잠시 접어두는 게 해답이다. 잠시 나가서 숨 좀 고르고 오는 편이 낫다. 그렇다고 무작정 손 놓으란 이야기는 아니다. 관련 커뮤니티에 질문을 올려놓고 밖으로 나서면, 원하는 답변을 얻을 때가 많다.

MSTest를 도입하려고 무척 애를 쓰던 무렵에 Visual Studio 2008로 넘어오면서 XML 출력 양식이 바뀌었다는 사실을 알게 됐다. 그런데 아무리 검색을 해도 원하는 답변이 안 나왔고, 어쩔 수 없이 CruiseControl .NET 메일링 리스트에 질문을 올렸다. 제대로 된 답변을 제때 얻을 수 있을지 의문스러웠지만, 뾰족한 수도 없었다. 그런데 바람 좀 쐬고 돌아오니 답장이 와 있었다. Visual Studio 2008용 XSL 파일을 만든 Alex Hutton 자신이 내 질문을 보고 답변을 준 것이다. 덕분에 골치 아팠던 문제를 금세 해결하고 본업(프로그램 짜기)으로 돌아갈 수 있었다.

막힐 때는 메일링 리스트를 활용해보자. 서툰 영어라도 다 알아듣는다.

NUnit

앞서 이야기했지만, 이 칼럼에선 NUnit를 닷넷 프레임워크용 단위 테스트 도구로 채택한다. NUnit은 MSTest 같은 도구가 세상에 나오기 훨씬 전부터 존재했다. 그만큼 역사가 오래됐고, 사용자가 많으며, 검증이 잘 됐다. NAnt와 달리 닷넷 프레임워크 새 버전이 나올 때마다 발 빠르게 대응해온 점도 높이 산다. GUI, 콘솔, XML 출력 등도 모두 지원하며 다양한 애드인과 추가 기능을 손쉽게 구할 수 있다.

NUnit도 물론 아쉬운 점이 있다. 무엇보다 비주얼 스튜디오와 연동하려면 별도의 도구를 구매해야 한다는 점이다(주요 도구의 목록: http://www.nunit.org/index.php?p=runners). 예전엔 공짜로 제공되는 도구가 많았지만, 그 중 일부는 유료가 됐고, 또 일부는 역사의 뒤안길로 사라져 지금은 업데이트가 안 되고 있다. 개인적으로 추천하는 도구로는 Resharper와 TestDriven .NET이 있다. 안타깝게도 둘 다 유료 소프트웨어다. 물론 이런 도구가 없어도 괜찮지만, 단위 테스트 코드를 디버깅할 때 특히 편리하여 생산성을 높여준다. 단, 빌드 서버에선 이런 도구를 쓰지 않으므로 개인 개발자용 라이선스만 구입하면 될 것이다.

C++/CLI를 위한 단위 테스트

C++/CLI 프로젝트는 크게 두 가지 모드가 있다. 하나는 순수하게 관리되는 타입만 쓰는 것이다. 이는 사실상 C# 프로젝트와 다를 바 없고, 단지 프로그래밍 언어의 문법적 차이만 있을 뿐이다. 하지만 이런 용도로 C++/CLI를 쓰는 사람은 거의 없다. 무엇보다 문법이 복잡해서 실수하기 쉽기 때문에 차라리 C#을 새로 익히는 편이 빠르기 때문이다. 보통 C++/CLI는 기존 네이티브 C++ 프로젝트와 C# 프로젝트를 연동하거나, 네이티브 라이브러리 또는 애플리케이션에서 닷넷 프레임워크의 풍부한 기능을 활용하고 싶을 때 사용한다. 이러한 경우를 두고 혼합 (Mixed) 모드라 한다.

순수하게 관리되는 타입만 썼다면, C#용 단위 테스트 프레임워크를 써도 된다. 중간 언어로 컴파일되고 나면 C++/CLI으로 작성한 코드나 C#으로 작성한 코드나 똑같아지기 때문이다.

만약 혼합 모드라면, 네이티브 C++용 단위 테스트 프레임워크를 쓰면 된다. 단위 테스트 프로젝트를 혼합 모드로 컴파일하면 네이티브 기능과 관리되는 기능을 모두 테스트할 수 있다. 내 경우엔 UnitTest++을 활용해 실제로 C++/CLI 혼합 코드를 테스트하고 있고, 여태까지 별다른 문제가 없었다. 물론 말처럼 쉽게만 되는 건 아니라서 몇 가지 알아야 할 점이 있는데, 이는 다음에 알아보도록 하자.