Qt Test 개요

Qt Test 는 Qt 기반 애플리케이션 및 라이브러리를 위한 단위 테스트 프레임워크입니다. Qt Test 는 일반적인 단위 테스트 프레임워크에서 제공하는 모든 기능은 물론, 그래픽 사용자 인터페이스(GUI) 테스트를 위한 확장 기능도 제공합니다.

Qt Test 는 Qt 기반 애플리케이션 및 라이브러리에 대한 단위 테스트 작성을 용이하게 하도록 설계되었습니다:

Qt Creator 마법사를 사용하여 Qt 테스트가 포함된 프로젝트를 생성하고, Qt Creator 에서 직접 빌드 및 실행할 수 있습니다. 자세한 내용은 Qt Creator: 테스트 빌드 및 실행을 참조하십시오.

테스트 생성

테스트를 생성하려면 QObject 의 서브클래스를 만들고, 여기에 하나 이상의 비공개 슬롯을 추가하십시오. 각 비공개 슬롯은 테스트 내의 테스트 함수입니다. QTest::qExec()를 사용하여 테스트 객체 내의 모든 테스트 함수를 실행할 수 있습니다.

또한, 테스트 함수로 취급되지 않는 다음의 비공개 슬롯을 정의할 수 있습니다. 이러한 슬롯이 정의되어 있으면 테스트 프레임워크에 의해 실행되며, 전체 테스트나 현재 테스트 함수를 초기화하거나 정리하는 데 사용할 수 있습니다.

• initTestCase() 첫 번째 테스트 함수가 실행되기 전에 호출됩니다.
• initTestCase_data() 는 전역 테스트 데이터 테이블을 생성하기 위해 호출됩니다.
• cleanupTestCase() 마지막 테스트 함수가 실행된 후에 호출됩니다.
• init() 각 테스트 함수가 실행되기 전에 호출됩니다.
• cleanup() 모든 테스트 함수가 실행된 후에 호출됩니다.

테스트 준비에는 ` initTestCase() `를 사용하십시오. 모든 테스트는 시스템을 반복적으로 실행할 수 있도록 사용 가능한 상태로 유지해야 합니다. 정리 작업은 ` cleanupTestCase()`에서 처리되어야 하며, 이는 테스트가 실패하더라도 해당 작업이 실행되도록 하기 위함입니다.

테스트 함수를 준비할 때는 ` init() `를 사용하십시오. 모든 테스트 함수는 시스템을 사용 가능한 상태로 유지해야 하며, 이를 통해 반복적으로 실행될 수 있습니다. 정리 작업은 ` cleanup()`에서 처리해야 하며, 이렇게 하면 테스트 함수가 실패하여 조기에 종료되더라도 해당 작업이 실행됩니다.

또는 RAII(resource acquisition is initialization)를 사용하여 소멸자에서 정리 작업을 호출함으로써, 테스트 함수가 반환되고 객체가 스코프 밖으로 빠져나갈 때 해당 작업이 확실히 수행되도록 할 수 있습니다.

initTestCase() 가 실패하면 어떤 테스트 함수도 실행되지 않습니다. init() 가 실패하면 다음 테스트 함수는 실행되지 않고, 테스트는 다음 테스트 함수로 진행됩니다.

예시:

class MyFirstTest: public QObject
{
    Q_OBJECT

private:
    bool myCondition()
    {
        return true;
    }

private slots:
    void initTestCase()
    {
        qDebug("Called before everything else.");
    }

    void myFirstTest()
    {
        QVERIFY(true); // 조건이 충족되는지 확인
        QCOMPARE(1, 1); // 두 값 비교
    }

   void mySecondTest()
    {
        QVERIFY(myCondition());
        QVERIFY(1 != 2);
    }

    void cleanupTestCase()
    {
        qDebug("Called after myFirstTest and mySecondTest.");
    }
};

마지막으로, 테스트 클래스에 static public void initMain() 메서드가 있는 경우, QApplication 객체가 인스턴스화되기 전에 QTEST_MAIN 매크로에 의해 이 메서드가 호출됩니다. 이 기능은 5.14 버전에서 추가되었습니다.

더 많은 예제는 Qt Test 튜토리얼을 참조하십시오.

테스트 함수 타임아웃 시간 늘리기

QtTest 은 무한 루프 및 이와 유사한 버그를 감지하기 위해 각 테스트의 실행 시간을 제한합니다. 기본적으로 모든 테스트 함수 호출은 5분이 지나면 중단됩니다. 데이터 기반 테스트의 경우, 이 제한은 고유한 데이터 태그를 가진 각 호출에 적용됩니다. 이 타임아웃은 ` QTEST_FUNCTION_TIMEOUT ` 환경 변수를 설정하여 단일 호출에 허용되는 최대 밀리초 수로 구성할 수 있습니다. 테스트가 구성된 타임아웃보다 오래 걸리면 중단되고 ` qFatal() `가 호출됩니다. 그 결과, 테스트는 마치 충돌이 발생한 것처럼 기본적으로 중단됩니다.

Linux 또는 macOS에서 명령줄을 통해 ` QTEST_FUNCTION_TIMEOUT `를 설정하려면 다음을 입력하십시오:

QTEST_FUNCTION_TIMEOUT=900000
export QTEST_FUNCTION_TIMEOUT

Windows의 경우:

SET QTEST_FUNCTION_TIMEOUT=900000

그런 다음 이 환경 내에서 테스트를 실행하십시오.

또는 테스트 코드 내에서 프로그래밍 방식으로 환경 변수를 설정할 수도 있습니다. 예를 들어, 테스트 클래스의 initMain() 특수 메서드에서 다음과 같이 호출하면 됩니다:

qputenv("QTEST_FUNCTION_TIMEOUT", "900000");

타임아웃에 적합한 값을 계산하려면, 테스트가 일반적으로 얼마나 걸리는지 확인하고, 문제가 발생하지 않는 선에서 얼마나 더 오래 걸릴 수 있는지 결정하십시오. 그 더 긴 시간을 밀리초 단위로 변환하여 타임아웃 값을 구하십시오. 예를 들어, 몇 분이 걸리는 테스트가 느린 컴퓨터에서 최대 20분까지 걸려도 합리적이라고 판단된다면, 20 * 60 * 1000 = 1200000 를 곱하여 환경 변수를 위의 900000 대신 1200000 로 설정하십시오.

테스트 빌드

일반적으로 프로덕션 코드의 한 클래스를 테스트하는 하나의 테스트 클래스가 포함된 실행 파일을 빌드할 수 있습니다. 하지만 보통은 하나의 명령어를 실행하여 프로젝트 내 여러 클래스를 테스트하고 싶어 할 것입니다.

단계별 설명은 ‘단위 테스트 작성하기 ’를 참조하십시오.

CMake 및 CTest를 사용한 빌드

CMake와 CTest를 사용하여 테스트를 생성할 수 있습니다. CTest를 사용하면 테스트 이름과 일치하는 정규 표현식을 기준으로 테스트를 포함하거나 제외할 수 있습니다. 또한 테스트에 ` LABELS ` 속성을 적용하면, CTest는 해당 레이블을 기준으로 테스트를 포함하거나 제외할 수 있습니다. 명령줄에서 ` test ` 타깃을 호출하면 레이블이 지정된 모든 타깃이 실행됩니다.

CMake에는 그 밖에도 여러 가지 장점이 있습니다. 예를 들어, CDash를 사용하면 거의 별도의 노력 없이 테스트 실행 결과를 웹 서버에 게시할 수 있습니다.

CTest는 매우 다양한 단위 테스트 프레임워크에 확장 가능하며, QTest 와 함께 바로 사용할 수 있습니다.

다음은 프로젝트 이름과 사용 언어(여기서는 mytest와 C++), 테스트 빌드에 필요한 Qt 모듈(Qt Test), 그리고 테스트에 포함되는 파일(tst_mytest.cpp)을 지정하는 CMakeLists.txt 파일의 예시입니다.

project(mytest LANGUAGES CXX)

find_package(Qt6 REQUIRED COMPONENTS Test)

set(CMAKE_INCLUDE_CURRENT_DIR ON)

set(CMAKE_AUTOMOC ON)

enable_testing(true)

qt_add_executable(mytest tst_mytest.cpp)
add_test(NAME mytest COMMAND mytest)

target_link_libraries(mytest PRIVATE Qt::Test)

사용 가능한 옵션에 대한 자세한 내용은 ‘CMake를 사용한 빌드’를 참조하십시오.

qmake를 사용한 빌드

qmake 를 빌드 도구로 사용하는 경우, 프로젝트 파일에 다음 내용을 추가하기만 하면 됩니다:

QT += testlib

make check 를 통해 테스트를 실행하려면 다음 줄을 추가하십시오:

CONFIG += testcase

테스트가 대상 시스템에 설치되는 것을 방지하려면 다음 줄을 추가하십시오:

CONFIG += no_testcase_installs

make check 에 대한 자세한 내용은 qmake 매뉴얼 을 참조하십시오.

다른 도구를 사용하여 빌드하기

다른 빌드 도구를 사용하는 경우, Qt Test 헤더 파일의 위치를 포함 경로(일반적으로 Qt 설치 디렉터리 내의 include/QtTest )에 추가해야 합니다. Qt의 릴리스 빌드를 사용하는 경우, 테스트 프로그램을 QtTest 라이브러리에 링크하십시오. 디버그 빌드의 경우 QtTest_debug 를 사용하십시오.

Qt Test 명령줄 인수

구문

자동 테스트를 실행하는 구문은 다음과 같은 간단한 형식을 따릅니다:

testname [options] [testfunctions[:testdata]]...

testname 를 실행 파일 이름으로 대체하십시오. testfunctions 에는 실행할 테스트 함수의 이름을 포함할 수 있습니다. testfunctions 가 전달되지 않으면 모든 테스트가 실행됩니다. testdata 에 있는 항목의 이름을 추가하면, 해당 테스트 함수는 해당 테스트 데이터로만 실행됩니다.

예를 들어:

/myTestDirectory$ testQString toUpper

toUpper 라는 테스트 함수를 사용 가능한 모든 테스트 데이터로 실행합니다.

/myTestDirectory$ testQString toUpper toInt:zero

사용 가능한 모든 테스트 데이터로 toUpper 테스트 함수를 실행하고, zero 라는 테스트 데이터 행을 사용하여 toInt 테스트 함수를 실행합니다(지정된 테스트 데이터가 존재하지 않으면 관련 테스트가 실패하고 사용 가능한 데이터 태그가 보고됩니다).

/myTestDirectory$ testMyWidget -vs -eventdelay 500

testMyWidget 함수 테스트를 실행하고, 모든 신호 발신을 출력하며, 시뮬레이션된 마우스/키보드 이벤트가 발생할 때마다 500밀리초 동안 대기합니다.

옵션

로깅 옵션

다음 명령줄 옵션은 테스트 결과가 보고되는 방식을 결정합니다:

• -o filename,format
  Writes output to the specified file, in the specified format (one of txt, csv, junitxml, xml, lightxml, teamcity or tap). Use the special filename - (hyphen) to log to standard output.
• -o 파일명
  지정된 파일에 결과를 기록합니다.
• -txt
  결과를 일반 텍스트로 출력합니다.
• -csv
  스프레드시트에 가져오기에 적합한 쉼표로 구분된 값(CSV) 형식으로 결과를 출력합니다. 이 모드는 일반적인 합격/불합격 메시지를 표시하지 않으므로 벤치마크 용도로만 적합합니다.
• -junitxml
  결과를 JUnit XML 문서로 출력합니다.
• -xml
  결과를 XML 문서로 출력합니다.
• -lightxml
  결과를 XML 태그 스트림으로 출력합니다.
• -teamcity
  결과를 TeamCity 형식으로 출력합니다.
• -tap
  결과를 TAP( Test Anything Protocol ) 형식으로 출력합니다.

-o 옵션의 첫 번째 버전을 반복하여 테스트 결과를 여러 형식으로 기록할 수 있지만, 이 옵션을 사용하여 표준 출력에 테스트 결과를 기록할 수 있는 인스턴스는 하나만 허용됩니다.

-o 옵션의 첫 번째 버전을 사용하는 경우, -o 옵션의 두 번째 버전이나 -txt, -xml, -lightxml, -teamcity, -junitxml, -tap 옵션은 함께 사용해서는 안 됩니다.

-o 옵션의 두 버전 중 어느 것도 사용되지 않으면, 테스트 결과가 표준 출력으로 기록됩니다. 형식 옵션이 사용되지 않으면, 테스트 결과가 일반 텍스트로 기록됩니다.

테스트 로그 세부 정보 옵션

다음 명령줄 옵션은 테스트 로그에 보고되는 세부 정보의 수준을 제어합니다:

• -silent
  간결한 출력; 치명적인 오류, 테스트 실패 및 최소한의 상태 메시지만 표시합니다.
• -v1
  상세한 출력; 각 테스트 함수가 호출될 때마다 표시합니다. (이 옵션은 일반 텍스트 출력에만 영향을 미칩니다.)
• -v2
  Extended verbose output; shows each QCOMPARE() and QVERIFY(). (This option affects all output formats and implies -v1 for plain text output.)
• -vs
  발생하는 모든 신호와 해당 신호로 인해 호출되는 슬롯을 표시합니다. (이 옵션은 모든 출력 형식에 적용됩니다.)

테스트 옵션

다음 명령줄 옵션은 테스트 실행 방식에 영향을 미칩니다:

• -functions
  테스트에서 사용할 수 있는 모든 테스트 함수를 출력한 후 종료합니다.
• -datatags
  테스트에서 사용할 수 있는 모든 데이터 태그를 출력합니다. 전역 데이터 태그 앞에는 ' __global__ '이 붙습니다.
• -eventdelay ms
  If no delay is specified for keyboard or mouse simulation (QTest::keyClick(), QTest::mouseClick() etc.), the value from this parameter (in milliseconds) is substituted.
• -keydelay ms
  -eventdelay와 유사하지만, 키보드 시뮬레이션에만 영향을 미치고 마우스 시뮬레이션에는 영향을 미치지 않습니다.
• -mousedelay ms
  -eventdelay와 유사하지만, 마우스 시뮬레이션에만 영향을 미치고 키보드 시뮬레이션에는 영향을 미치지 않습니다.
• -maxwarnings number
  출력할 경고의 최대 개수를 설정합니다. 0은 제한 없음을 의미하며, 기본값은 2000입니다.
• -nocrashhandler
  Unix 플랫폼에서 크래시 핸들러를 비활성화합니다. Windows에서는 기본적으로 비활성화되어 있는 Windows 오류 보고 대화 상자를 다시 활성화합니다. 이는 크래시 디버깅에 유용합니다.
• -repeat n
  테스트 스위트를 n회 실행하거나 테스트가 실패할 때까지 실행합니다. 불안정한 테스트를 찾는 데 유용합니다. 음수 값을 지정하면 테스트가 무한히 반복됩니다. 이는 개발자용 도구로 의도되었으며, 일반 텍스트 로거에서만 지원됩니다.
• -skipblacklisted
  블랙리스트에 등록된 테스트를 건너뜁니다. 이 옵션은 블랙리스트에 등록된 테스트가 커버리지 통계를 부풀리는 것을 방지하여 테스트 커버리지를 더 정확하게 측정할 수 있도록 하기 위한 것입니다. 테스트 커버리지를 측정하지 않을 때는 블랙리스트에 등록된 테스트를 실행하여 새로운 충돌 발생이나 블랙리스트 등록 원인이 된 문제가 해결되었는지 등 결과의 변화를 확인하는 것이 좋습니다.
• -platform name
  This command line argument applies to all Qt applications, but might be especially useful in the context of auto-testing. By using the "offscreen" platform plugin (-platform offscreen) it's possible to have tests that use QWidget or QWindow run without showing anything on the screen. Currently the offscreen platform plugin is only fully supported on X11.

벤치마킹 옵션

다음 명령줄 옵션은 벤치마크 테스트를 제어합니다:

• -callgrind
  Callgrind를 사용하여 벤치마크 시간을 측정합니다(Linux 및 macOS).
• -perf
  Linux perf 이벤트를 사용하여 벤치마크 시간을 측정합니다.
• -tickcounter
  CPU 틱 카운터를 사용하여 벤치마크 시간을 측정합니다. 하드웨어 지원이 필요합니다.
• -eventcounter
  벤치마크 실행 중 수신된 이벤트 수를 집계합니다.
• -minimumvalue n
  허용 가능한 최소 측정값을 설정합니다.
• -minimumtotal n
  테스트 함수의 반복 실행에 대해 허용 가능한 최소 총 횟수를 설정합니다.
• -iterations n
  누적 반복 횟수를 설정합니다.
• -median n
  중앙값 반복 횟수를 설정합니다.
• -vb
  상세한 벤치마킹 정보를 출력합니다.

기타 옵션

• -help
  사용 가능한 명령줄 인수를 출력하고 유용한 도움말을 제공합니다.

Qt Test 환경 변수

자동 테스트 실행에 영향을 주기 위해 특정 환경 변수를 설정할 수 있습니다:

• QTEST_DISABLE_CORE_DUMP
  이 변수를 0이 아닌 값으로 설정하면 코어 덤프 파일 생성이 비활성화됩니다.
• QTEST_DISABLE_STACK_DUMP
  이 변수를 0이 아닌 값으로 설정하면, 자동 테스트가 시간 초과되거나 충돌하는 경우 Qt Test가 스택 트레이스를 출력하지 않게 됩니다.
• QTEST_FATAL_FAIL
  이 변수를 0이 아닌 값으로 설정하면 자동 테스트에서 오류가 발생했을 때 전체 자동 테스트가 즉시 중단됩니다. 이는 디버거에서 테스트를 실행하여 불안정하거나 간헐적으로 발생하는 테스트 오류를 디버깅하는 데 유용합니다. 이 변수에 대한 지원은 Qt 6.1부터 추가되었습니다.

벤치마크 생성

벤치마크를 생성하려면 테스트 생성 지침을 따르고, 벤치마크를 수행할 테스트 함수에 ` QBENCHMARK ` 매크로 또는 ` QTest::setBenchmarkResult()`를 추가하십시오. 다음 코드 예제에서는 매크로가 사용되었습니다:

class MyFirstBenchmark: public QObject
{
    Q_OBJECT
private slots:
    void myFirstBenchmark()
    {
        QString string1;
        QString string2;
        QBENCHMARK {
            string1.localeAwareCompare(string2);
        }
    }
};

성능을 측정하는 테스트 함수에는 단일 QBENCHMARK 매크로 또는 setBenchmarkResult() 호출이 하나만 포함되어야 합니다. 테스트 함수당, 또는 데이터 기반 설정의 데이터 태그당 하나의 성능 결과만 보고될 수 있으므로, 여러 번 포함하는 것은 의미가 없습니다.

QBENCHMARK 매크로의 본문을 구성하거나 이에 영향을 미치는 테스트 코드, 또는 setBenchmarkResult() 에 전달되는 값을 계산하는 테스트 코드는 변경하지 마십시오. 연속적인 성능 결과의 차이는 이상적으로는 테스트 중인 제품의 변경에 의해서만 발생해야 합니다. 테스트 코드를 변경하면 성능 변화에 대한 오해의 소지가 있는 보고 결과가 나올 수 있습니다. 테스트 코드를 변경해야 할 경우, 커밋 메시지에 그 사실을 명확히 기재하십시오.

성능 테스트 함수에서는 QBENCHMARK 또는 setBenchmarkResult() 호출 후, QCOMPARE(), QVERIFY() 등을 사용하여 검증 단계를 수행해야 합니다. 의도한 코드 경로와 다른 경로가 측정된 경우, 해당 성능 결과를 무효로 표시할 수 있습니다. 성능 분석 도구는 이 정보를 활용하여 무효한 결과를 걸러낼 수 있습니다. 예를 들어, 예기치 않은 오류 조건이 발생하면 일반적으로 프로그램이 정상적인 실행 과정에서 조기에 종료되어, 결과적으로 성능이 급격히 향상된 것처럼 잘못 표시될 수 있습니다.

측정 백엔드 선택

QBENCHMARK 매크로 내부의 코드가 측정되며, 정확한 측정 결과를 얻기 위해 여러 번 반복될 수도 있습니다. 이는 선택한 측정 백엔드에 따라 달라집니다. 여러 가지 백엔드를 사용할 수 있으며, 명령줄에서 선택할 수 있습니다( 벤치마킹 옵션 참조):

간단히 말해, walltime은 항상 사용할 수 있지만 유용한 결과를 얻으려면 많은 반복 실행이 필요합니다. 틱 카운터는 일반적으로 사용할 수 있으며 적은 반복 횟수로 결과를 제공할 수 있지만, CPU 주파수 스케일링 문제의 영향을 받을 수 있습니다. Valgrind는 정확한 결과를 제공하지만 I/O 대기 시간을 고려하지 않으며, 제한된 수의 플랫폼에서만 사용할 수 있습니다. 이벤트 카운팅은 모든 플랫폼에서 사용할 수 있으며, 해당 이벤트가 대응하는 대상(Qt 이벤트가 아닐 수도 있음)으로 전송되기 전에 이벤트 루프가 수신한 이벤트의 수를 제공합니다.

Linux 성능 모니터링 솔루션은 Linux에서만 사용할 수 있으며, 추가 옵션 -perfcounter countername 을 전달하여 선택할 수 있는 다양한 카운터를 제공합니다. 예를 들어, -perfcounter cache-misses, -perfcounter branch-misses 또는 -perfcounter l1d-load-misses 등이 있습니다. 기본 카운터는 cpu-cycles 입니다. 카운터의 전체 목록은 -perfcounterlist 옵션을 사용하여 벤치마크 실행 파일을 실행하면 확인할 수 있습니다.

• 성능 카운터를 사용하려면 비특권 애플리케이션에 대한 액세스를 활성화해야 할 수 있습니다.
• 고해상도 타이머를 지원하지 않는 장치의 경우 기본적으로 1밀리초 단위로 설정됩니다.

더 많은 벤치마킹 예제는 ‘ Qt Test ’ 튜토리얼의 ‘벤치마크 작성’ 섹션을 참조하십시오.

전역 테스트 데이터 사용

initTestCase_data() 를 정의하여 전역 테스트 데이터 테이블을 설정할 수 있습니다. 각 테스트는 전역 테스트 데이터 테이블의 각 행에 대해 한 번씩 실행됩니다. 테스트 함수 자체가 데이터 기반인 경우, 로컬 데이터 행마다, 전역 데이터 행마다 테스트가 실행됩니다. 따라서 전역 데이터 테이블에 g 개의 행이 있고 테스트 자체의 데이터 테이블에 d 개의 행이 있다면, 이 테스트의 실행 횟수는 g × d 이 됩니다.

전역 데이터는 QFETCH_GLOBAL() 매크로를 사용하여 테이블에서 가져옵니다.

다음은 전역 테스트 데이터의 일반적인 사용 사례입니다:

• QSql 테스트에서 사용 가능한 데이터베이스 백엔드 중 하나를 선택하여 모든 테스트를 모든 데이터베이스에서 실행합니다.
• SSL 사용 및 미사용(HTTP 대 HTTPS) 및 프록시 사용 여부에 따라 모든 네트워킹 테스트를 수행하는 경우.
• 정밀도가 높은 시계와 정밀도가 낮은 시계를 사용하여 타이머를 테스트하는 것.
• 파서가 QByteArray 에서 읽을지, 아니면 QIODevice 에서 읽을지 선택하는 것.

예를 들어, roundTripInt_data() 에서 제공하는 각 숫자를 initTestCase_data() 에서 제공하는 각 로케일과 조합하여 테스트하려면:

void TestQLocale::roundTripInt()
{
    QFETCH_GLOBAL(QLocale, locale);
    QFETCH(int, number);
    bool ok;
    QCOMPARE(locale.toInt(locale.toString(number), &ok), number);
    QVERIFY(ok);
}

테스트의 명령줄에서 함수 이름(test-class-name 접두사 없이)을 전달하면 해당 함수의 테스트만 실행할 수 있습니다. 테스트 클래스에 전역 데이터가 있거나 함수가 데이터 기반인 경우, 콜론 뒤에 데이터 태그를 추가하여 해당 함수에 대한 해당 태그의 데이터 세트만 실행할 수 있습니다. 전역 태그와 테스트 함수 전용 태그를 모두 지정하려면, 콜론을 사이에 두고 결합하되 전역 데이터 태그를 먼저 배치하십시오. 예를 들어

./testqlocale roundTripInt:zero

는 위의 roundTripInt() 테스트 중 zero 테스트 케이스를 (해당 TestQLocale 클래스가 실행 파일 testqlocale 로 컴파일되었다고 가정할 때) initTestCase_data() 에 지정된 각 로케일에서 실행하며, 반면

./testqlocale roundTripInt:C

roundTripInt() 의 세 가지 테스트 케이스를 모두 C 로케일에서만 실행하며,

./testqlocale roundTripInt:C:zero

zero 의 테스트 케이스 중 하나만 C 로케일에서 실행합니다.

실행할 테스트를 이처럼 세밀하게 제어할 수 있다면, 실패한 것으로 확인된 단 하나의 테스트 케이스만 단계별로 추적하면 되므로 문제 디버깅이 상당히 수월해집니다.