Qt Test 개요

Qt Test 는 Qt 기반 애플리케이션과 라이브러리를 단위 테스트하기 위한 프레임워크입니다. Qt Test 는 그래픽 사용자 인터페이스 테스트를 위한 확장 기능뿐만 아니라 단위 테스트 프레임워크에서 흔히 볼 수 있는 모든 기능을 제공합니다.

Qt Test 는 Qt 기반 애플리케이션과 라이브러리에 대한 단위 테스트를 쉽게 작성할 수 있도록 설계되었습니다:

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

테스트 생성하기

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

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

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

테스트를 준비하려면 initTestCase() 을 사용합니다. 모든 테스트는 반복적으로 실행할 수 있도록 시스템을 사용 가능한 상태로 유지해야 합니다. 정리 작업은 cleanupTestCase() 에서 처리해야 테스트가 실패하더라도 실행됩니다.

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

또는 소멸자에서 호출되는 정리 작업과 함께 RAII(리소스 획득은 초기화)를 사용하여 테스트 함수가 반환되고 객체가 범위를 벗어날 때 정리 작업이 수행되도록 할 수 있습니다.

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

예시:

MyFirstTest 클래스: public QObject
{ Q_OBJECTprivate: 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.");
    } };

마지막으로 테스트 클래스에 정적 공용 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 target을 호출할 때 실행됩니다.

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

CTest는 매우 다양한 단위 테스트 프레임워크로 확장할 수 있으며 QTest 에서 바로 사용할 수 있습니다.

다음은 프로젝트 이름과 사용된 언어(여기서는 mytest와 C++), 테스트 빌드에 필요한 Qt 모듈(Qt5Test), 테스트에 포함된 파일(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 파일 이름, 형식
  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 이름
  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만 해당).
• -tickcounter
  CPU 틱 카운터를 사용하여 벤치마크 시간을 측정합니다.
• -eventcounter
  벤치마크 중에 수신된 이벤트를 카운트합니다.
• -minimumvalue n
  허용 가능한 최소 측정값을 설정합니다.
• -minimumtotal n
  테스트 함수의 반복 실행에 허용되는 최소 총합을 설정합니다.
• -iterations n
  누적 반복 횟수를 설정합니다.
• -median n
  중앙값 반복 횟수를 설정합니다.
• -vb
  자세한 벤치마킹 정보를 출력합니다.

기타 옵션

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

Qt Test 환경 변수

특정 환경 변수를 설정하여 자동 테스트 실행에 영향을 줄 수 있습니다:

• QTEST_DISABLE_CORE_DUMP
  
• QTEST_DISABLE_STACK_DUMP
  이 변수를
• 0이 아닌 값으로 설정하면 코어 덤프 파일 생성을 비활성화합니다.
• QTEST_FATAL_FAIL
  이 변수를 0이 아닌
• 값으로 설정하면 자동 테스트가 시간 초과되거나 충돌하는 경우 Qt Test가 스택 추적을 인쇄하지 않습니다.
• 이 변수는 예를 들어 디버거에서 테스트를 실행하여 테스트의 불안정하거나 간헐적인 오류를 디버깅하는 데 유용합니다. 이 변수에 대한 지원은 Qt 6.1에서 추가되었습니다.
• QTEST_THROW_ON_FAIL (6.8 이후)
  Setting this variable to a non-zero value will cause QCOMPARE()/QVERIFY() etc to throw on failure (as opposed to just returning from the immediately-surrounding function scope).
• QTEST_THROW_ON_SKIP (6.8 이후)
  Same as QTEST_THROW_ON_FAIL, except affecting QSKIP().

벤치마크 만들기

벤치마크를 만들려면 테스트 만들기 지침에 따라 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 매크로 내부의 코드가 측정되며, 정확한 측정을 위해 여러 번 반복될 수도 있습니다. 이는 선택한 측정 백엔드에 따라 다릅니다. 여러 백엔드를 사용할 수 있습니다. 백엔드는 명령줄에서 선택할 수 있습니다:

간단히 말해, 월타임은 항상 사용할 수 있지만 유용한 결과를 얻으려면 많은 반복이 필요합니다. 틱 카운터는 일반적으로 사용할 수 있으며 더 적은 반복으로 결과를 제공할 수 있지만 CPU 주파수 스케일링 문제에 취약할 수 있습니다. Valgrind는 정확한 결과를 제공하지만 I/O 대기를 고려하지 않으며 제한된 수의 플랫폼에서만 사용할 수 있습니다. 이벤트 카운팅은 모든 플랫폼에서 사용할 수 있으며 이벤트 루프가 해당 타겟으로 전송되기 전에 수신한 이벤트의 수를 제공합니다(여기에는 Qt가 아닌 이벤트가 포함될 수 있음).

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

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

더 많은 벤치마킹 예제는 Qt Test 튜토리얼에서 벤치마크 작성하기를 참조하세요.

글로벌 테스트 데이터 사용

initTestCase_data() 을 정의하여 글로벌 테스트 데이터 테이블을 설정할 수 있습니다. 각 테스트는 글로벌 테스트 데이터 테이블의 각 행에 대해 한 번씩 실행됩니다. 테스트 함수 자체가 데이터 기반인 경우 각 로컬 데이터 행, 각 글로벌 데이터 행에 대해 실행됩니다. 따라서 글로벌 데이터 테이블에 g 행이 있고 테스트 자체 데이터 테이블에 d 행이 있는 경우, 이 테스트의 실행 횟수는 g x 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

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

./testqlocale roundTripInt:C:zero

는 C 로캘에서 zero 테스트 케이스만 실행합니다.

실행할 테스트를 이렇게 세밀하게 제어하면 실패한 것으로 확인된 테스트 케이스 하나만 실행하면 되므로 문제를 디버깅하기가 훨씬 쉬워집니다.