catchorg/Catch2 딥다이브
— C++를 위한 현대적 단위 테스트 프레임워크

1프로젝트 한 줄 요약

Catch2는 "C++ 코드에게 시험지를 내고 자동 채점하는 도구"다. 내가 만든 함수 Factorial(3)이 정말 6을 돌려주는지, 조건을 바꿔도 안 깨지는지를 사람이 매번 눈으로 확인하는 대신, 테스트 코드로 한 번 적어두면 빌드할 때마다 기계가 대신 확인해 준다. 이런 도구를 단위 테스트 프레임워크(unit test framework)라 부른다.

이름의 유래가 성격을 잘 말해준다. 원조 "Catch"는 C++ Automated Test Cases in Headers의 머리글자로, "헤더 파일 하나만 include하면 바로 쓰는 테스트 도구"라는 뜻이었다. Catch2는 그 2세대이며, 현재 배포되는 v3는 "헤더 하나" 철학을 일부 내려놓고 컴파일 라이브러리로 재설계했다(왜 그랬는지는 §2·§4에서 자세히).

2왜 지금 주목받는가

Catch2는 갓 나온 신생 프로젝트가 아니라, C++ 세계에서 오래 쓰여온 대표 테스트 프레임워크 중 하나다. 그런 성숙한 저장소가 트렌딩에 다시 오른다는 건, 최근 릴리스·C++ 생태계의 관심이 이 프로젝트로 몰리고 있다는 신호다. (TrendShift의 굵은 숫자는 별 수가 아니라 사회적 언급 모멘텀이다.) 사랑받는 이유를 네 갈래로 정리한다.

주목 포인트 1 — "외울 매크로가 없다" (표현식 분해)

GoogleTest는 EXPECT_EQ, EXPECT_NE, EXPECT_LT, EXPECT_GT… 비교마다 다른 매크로를 쓴다. Catch2는 전부 REQUIRE(...) 하나로 끝난다. REQUIRE(a == b), REQUIRE(x < y), REQUIRE(v.size() >= 3) — 그냥 참/거짓이 되는 평범한 C++ 표현식을 넣으면, 실패 시 양쪽 값을 알아서 출력한다. 배울 게 적고, 코드가 자연어처럼 읽힌다.

주목 포인트 2 — fixture 없는 SECTION 트리 모델

보통 프레임워크에서 "공통 준비 코드"를 공유하려면 SetUp()/TearDown()이 있는 fixture 클래스를 만들어야 한다. Catch2는 SECTION마다 TEST_CASE 본문을 통째로 다시 실행하는 방식이라, 준비 코드를 그냥 함수 맨 위에 지역 변수로 두면 각 SECTION이 매번 새 복사본을 받는다. 클래스·상속 없이 setup/teardown이 해결되는 독특하고 직관적인 설계다.

주목 포인트 3 — 테스트에 필요한 게 다 들어 있다 (올인원)

단순 assertion만이 아니다. BDD 문법(SCENARIO/GIVEN/WHEN/THEN), 마이크로 벤치마크(BENCHMARK), 매트처(Matchers), 데이터 주도 테스트(GENERATE)가 전부 기본 내장이다. 성능 회귀를 재려고 별도 벤치마크 라이브러리를 붙이거나, 파라미터라이즈드 테스트를 위해 부가 도구를 찾을 필요가 없다. "하나로 다 되는" 완결성이 강점이다.

주목 포인트 4 — v3의 컴파일 타임 혁신

v2 시절 Catch2는 "헤더 하나"라 편했지만, 테스트 파일마다 프레임워크 전체를 매번 재컴파일해 빌드가 느려지는 약점이 있었다. v3는 프레임워크를 정적 라이브러리로 한 번만 컴파일하고 사용자 코드는 가벼운 선언 헤더만 include하도록 바꿔, 공식 문서 기준 포함(inclusion) 오버헤드를 약 80% 줄였다. "느려서 doctest로 갈아탄다"던 사람들을 붙잡은 결정적 개선이다(§4-6).

경쟁 프레임워크 비교

3기술 스택 전체 지도

Catch2의 스택은 의외로 단출하다. 외부 런타임 의존성이 하나도 없다 — 오직 C++ 표준 라이브러리만 쓴다. 대신 진짜 복잡함은 "이 라이브러리를 어떻게 컴파일하고, 사용자 프로젝트에 어떻게 물리느냐"라는 빌드·통합 쪽에 있다. 세 계층으로 나눠 본다.

계층 1 — 언어 · 표준 (프레임워크의 토대)

계층 2 — 라이브러리 내부 구성 (헤더/구현 분리)

v3의 핵심 스택 전략은 "인터페이스(선언)와 구현(정의)을 물리적으로 분리"하는 것이다. 사용자는 가벼운 선언 헤더만 include하고, 무거운 구현은 미리 컴파일된 .a/.lib에 담긴다.

계층 3 — 빌드 시스템 · 패키지 매니저 (소비 경로)

C++엔 표준 패키지 매니저가 없어서, Catch2는 거의 모든 빌드 도구에 대응한다.

4아키텍처 심화 분석

Catch2는 겉보기엔 매크로 몇 개지만, 그 안에는 C++ 템플릿·매크로·연산자 우선순위를 총동원한 정교한 장치가 숨어 있다. 이 절이 이 문서의 핵심 — 네 개의 메커니즘을 하나씩 해부한다.

4-1. 표현식 분해 — 연산자 우선순위 해킹 (catch_decomposer.hpp)

REQUIRE(a == b)는 어떻게 a와 b의 값을 둘 다 붙잡을까? 비밀은 매크로가 표현식 앞에 Catch::Decomposer{} <=를 몰래 끼워넣는 데 있다.

실제 코드는 이렇게 생겼다(핵심만 발췌):

struct Decomposer {
    template <typename T>
    constexpr friend auto operator <= ( Decomposer&&, T&& lhs ) -> ExprLhs<T const&> {
        return ExprLhs<const T&>{ lhs };   // LHS(a)를 먼저 붙잡는다
    }
};
// ExprLhs 안에는 ==, !=, <, >, <=, >= 연산자가 정의돼
// 각각 BinaryExpr<LhsT, RhsT>(양쪽 값 저장)를 만든다

포인트: <=가 ==보다 우선순위가 낮기 때문에 Decomposer{} <= a가 먼저 묶여 a가 포장되고, 그다음 == b가 처리된다. 사용자 타입에 비교 연산자 오버로드 보일러플레이트를 강요하지 않고도 양쪽 값을 스트림 출력할 수 있는 것이 이 트릭 덕분이다. 단, &&·||는 단락 평가 때문에 값을 못 붙잡으므로 assertion 안에서 static_assert로 금지된다(대신 매트처를 쓰라고 안내).

4-2. SECTION 트리 실행 모델

Catch2에서 가장 독특한 부분. 아래 예제(examples/100-Fix-Section.cpp)를 보자.

TEST_CASE( "vectors can be sized and resized", "[vector]" ) {
    std::vector<int> v( 5 );          // (A) 준비 코드 — SECTION마다 새로 실행됨
    REQUIRE( v.size() == 5 );

    SECTION( "resizing bigger" ) {
        v.resize( 10 );
        REQUIRE( v.size() == 10 );
    }
    SECTION( "resizing smaller" ) {
        v.resize( 0 );
        REQUIRE( v.size() == 0 );
    }
}

이 TEST_CASE는 두 번 실행된다. 첫 실행 때는 첫 SECTION만 "열리고" 둘째는 건너뛴다. 둘째 실행 때는 반대. 매 실행마다 (A)의 std::vector v(5)가 새로 만들어지므로, 한 SECTION에서 벡터를 망가뜨려도 다른 SECTION은 깨끗한 벡터로 시작한다. SECTION을 중첩하면 트리가 되고, Catch2는 매 실행에 리프(leaf) 하나씩 경로를 밟으며 모든 조합을 순회한다.

4-3. 테스트 자기등록 — 정적 초기화 트릭 (catch_test_registry.hpp)

TEST_CASE(...)를 쓰기만 하면 main()에 아무것도 안 적었는데 테스트가 실행된다. 어떻게? 매크로가 익명 네임스페이스에 전역 객체 하나를 심고, 그 생성자가 프로그램 시작 전(static init)에 테스트를 레지스트리에 등록하기 때문이다.

// TEST_CASE( "name", "[tag]" ) 는 대략 이렇게 펼쳐진다:
static void autoName();                    // (1) 사용자 테스트 함수 선언
namespace {
  const Catch::AutoReg autoRegistrar(       // (2) 전역 객체 — 생성자가 등록 실행
      Catch::makeTestInvoker( &autoName ),
      CATCH_INTERNAL_LINEINFO,
      Catch::StringRef(),
      Catch::NameAndTags{ "name", "[tag]" } );
}
static void autoName()                     // (3) 여기부터 사용자가 쓴 { ... } 본문

AutoReg 생성자가 함수 포인터를 전역 테스트 레지스트리에 밀어넣는다. 이름 충돌은 INTERNAL_CATCH_UNIQUE_NAME(__COUNTER__ 기반)으로 방지. 이 "전역 객체 생성자로 자기등록" 관용구는 플러그인·팩토리 자동 등록에 두루 쓰이는 C++ 패턴의 교과서 사례다.

4-4. 이벤트 기반 리포터 아키텍처 (interfaces/catch_interfaces_reporter.hpp)

테스트 결과를 콘솔·XML·JUnit 등 다양한 형식으로 뽑는 부분은 이벤트 리스너 패턴으로 설계됐다. 테스트가 진행되며 발생하는 사건마다 콜백이 불린다.

class IEventListener {
    virtual void testRunStarting( TestRunInfo const& ) = 0;
    virtual void testCaseStarting( TestCaseInfo const& ) = 0;
    virtual void sectionStarting( SectionInfo const& ) = 0;
    virtual void assertionEnded( AssertionStats const& ) = 0;   // REQUIRE 결과 하나
    virtual void testCaseEnded( TestCaseStats const& ) = 0;
    virtual void testRunEnded( TestRunStats const& ) = 0;
    // ... benchmarkStarting, listReporters 등
};

구현체는 두 부류로 갈린다 — streaming_base(결과가 나오는 대로 즉시 출력, 콘솔용)와 cumulative_base(전부 모았다가 마지막에 한꺼번에 출력, XML/JUnit처럼 문서 구조가 필요한 경우). 여러 리스너를 동시에 물릴 땐 multi 리포터가 팬아웃(fan-out)한다. 제공되는 출력 리포터는 9종이다.

4-5. 매트처 · 제너레이터 · 벤치마크

assertion 위에 얹히는 세 확장 기능. 각각 실제 문법을 보자.

매트처(Matchers) — REQUIRE_THAT

using Catch::Matchers::EndsWith;
using Catch::Matchers::ContainsSubstring;

REQUIRE_THAT( getSomeString(),
              EndsWith("as a service") && ContainsSubstring("web scale") );  // 매트처 합성
CHECK_THAT( value, WithinAbs(0, 2e-2) && !WithinULP(0., 1) );          // 부동소수점 비교

문자열(StartsWith·EndsWith·ContainsSubstring·Matches 정규식), 부동소수점(WithinAbs·WithinRel·WithinULP), 컨테이너(SizeIs·IsEmpty·UnorderedEquals·AllMatch) 등이 있고, &&·||·!로 합성된다. 부동소수점 비교처럼 ==로 표현 못 하는 검증을 자연스럽게 처리한다.

제너레이터(Generators) — GENERATE로 데이터 주도

TEST_CASE("Table 입력/출력", "[generator]") {
    auto [input, expected] = GENERATE( table<std::string, size_t>({
        { "one", 3 }, { "two", 3 }, { "three", 5 }, { "four", 4 } }) );
    REQUIRE( getLength(input) == expected );   // 4개 값마다 자동 재실행
}

GENERATE가 있는 SECTION은 생성된 값 개수만큼 자동 반복된다(SECTION 재실행 모델의 응용). table<>·range()·random()·values()와 커스텀 제너레이터로 파라미터라이즈드 테스트를 표현.

벤치마크(Benchmark) — BENCHMARK

TEST_CASE("Fibonacci 성능") {
    CHECK( Fibonacci(5) == 8 );
    BENCHMARK("Fibonacci 20") { return Fibonacci(20); };   // 세미콜론 필수(람다)
    BENCHMARK("Fibonacci 35") { return Fibonacci(35); };
}

BENCHMARK는 람다로 확장돼 자동 반복 측정 + 평균·표준편차·이상치(outlier) 분석까지 해준다. return을 쓰는 이유는 컴파일러가 "결과를 안 쓰네?" 하고 코드를 최적화로 지워버리는 것을 막기 위함(benchmark/catch_optimizer.hpp). 별도 벤치마크 라이브러리 없이 테스트와 성능 측정을 한 파일에서 한다.

4-6. v3 컴파일 타임 방화벽(firewall) 설계

왜 v3가 그렇게 빠른가를 그림으로 정리한다.

핵심은 interfaces/(추상 인터페이스)와 internal/(구현 139파일)의 물리적 분리다. 구현이 바뀌어도 사용자 TU가 include하는 건 인터페이스뿐이라 재빌드가 전파되지 않는다. 게다가 매트처·제너레이터·벤치마크는 쓰지 않으면 해당 헤더를 include하지 않으므로 컴파일 비용이 아예 발생하지 않는다. "안 쓰면 공짜"인 모듈러 설계가 대규모 C++ 라이브러리 아키텍처의 모범으로 꼽히는 이유다.

5디렉토리 구조 해부

Catch2의 저장소는 라이브러리 소스(src/) + 문서(docs/) + 예제(examples/) + 소비자용 헬퍼(extras/)로 나뉜다. 프레임워크 코드의 뼈대인 src/catch2/부터 본다.

최상위 디렉토리

6학습 포인트

Catch2는 "테스트 쓰는 법"을 넘어, 현대 C++의 고급 기법이 어떻게 실전에서 쓰이는지를 보여주는 살아있는 교재다. 기술별로 배울 거리를 정리한다.

배울 것 1 — 연산자 우선순위를 이용한 표현식 캡처

§4-1의 Decomposer{} <= a == b는 언어의 우선순위 규칙 자체를 도구로 쓰는 발상의 전환이다. 여기에 SFINAE(enable_if)로 값 캡처/참조 캡처를 분기하는 기법까지 얹혀 있다. "매크로로 표현식을 감싸고, 템플릿으로 그 표현식을 분해한다"는 매크로+템플릿 협업의 정수를 볼 수 있다.

배울 것 2 — 정적 초기화 기반 자기등록 패턴

§4-3의 AutoReg 관용구는 테스트뿐 아니라 플러그인·팩토리·직렬화 타입 등록에 두루 쓰인다. "익명 네임스페이스에 전역 객체를 만들고, 그 생성자가 main 이전에 중앙 레지스트리에 자기를 등록한다"는 패턴은 C++ 개발자라면 반드시 알아둘 도구다. __COUNTER__로 고유 심볼을 만드는 매크로 기법도 함께.

배울 것 3 — 컴파일 타임을 고려한 아키텍처

C++에서 컴파일 시간은 곧 개발 생산성이다. Catch2 v3가 인터페이스/구현을 분리(interfaces/ vs internal/)하고 기능별로 헤더를 쪼개 "안 쓰면 비용 0"을 달성한 방식은, 대규모 헤더 라이브러리를 설계할 때 그대로 참고할 만한 실전 아키텍처 결정이다.

배울 것 4 — 이벤트 기반 확장 설계

§4-4의 IEventListener 순수 가상 인터페이스 + 다형 리포터 + 멀티플렉서 구조는, 출력 형식(9종)과 커스텀 관찰자를 코어 수정 없이 플러그인화하는 방법을 보여준다. "확장 지점을 인터페이스로 열어두는" 개방-폐쇄 원칙(OCP)의 구체적 사례.

배울 것 5 — 매크로로 자연스러운 DSL 만들기

TEST_CASE·SECTION·GENERATE·BENCHMARK·SCENARIO는 전부 매크로지만, 트리 재실행·데이터 주도·람다 벤치마크 같은 고급 시맨틱을 자연어 같은 문법으로 노출한다. "매크로는 나쁘다"는 통념을 넘어, 언제 어떻게 매크로가 최선의 인터페이스가 되는지를 배운다.

7시스템 · 빌드 요구사항

Catch2는 실행 환경 요구가 매우 가볍다. C++14를 지원하는 컴파일러 하나면 되고, 외부 라이브러리 설치가 필요 없다.

실전 통합 — CMake FetchContent (가장 흔한 방법)

Include(FetchContent)
FetchContent_Declare(
  Catch2
  GIT_REPOSITORY https://github.com/catchorg/Catch2.git
  GIT_TAG        v3.15.2 )
FetchContent_MakeAvailable(Catch2)

target_link_libraries(tests PRIVATE Catch2::Catch2WithMain)   # main() 포함본을 링크

설치된 Catch2를 쓸 땐 find_package(Catch2 3 REQUIRED)로 바꾸면 된다. 커스텀 main()을 직접 쓰고 싶으면 Catch2::Catch2WithMain 대신 Catch2::Catch2(코어만)를 링크한다.

CTest 자동 등록 — catch_discover_tests

find_package(Catch2 REQUIRED)
include(Catch)                        # extras/Catch.cmake
target_link_libraries(tests PRIVATE Catch2::Catch2)
catch_discover_tests(tests)           # 바이너리를 실행해 개별 TEST_CASE를 CTest에 자동 등록

catch_discover_tests는 컴파일된 테스트 실행 파일을 한 번 돌려 그 안의 모든 TEST_CASE를 개별 CTest 테스트로 등록한다. 덕분에 ctest 한 줄로 병렬 실행·필터·재실행이 된다. 대규모 테스트는 CatchShardTests.cmake로 여러 머신에 쪼개(shard) 돌릴 수도 있다.

8직접 해볼 수 있는 실습 과제

9관련 기술 심화 학습 로드맵

10핵심 키워드 사전

11참고 링크