戰(zhàn)：從入門到工程化應(yīng)用與設(shè)計(jì)方法)
從實(shí)際項(xiàng)目經(jīng)驗(yàn)談 QTest 單元測試框架的應(yīng)用與設(shè)計(jì)思路做 Qt 開發(fā)久了尤其在項(xiàng)目規(guī)模變大、多人協(xié)作的節(jié)奏下一定會(huì)有這樣的時(shí)刻改了一個(gè)看似無關(guān)緊要的接口跑起來發(fā)現(xiàn)完全不是想的那樣甚至在老功能里莫名其妙引入了回歸問題。這個(gè)痛點(diǎn)我太熟悉了。后來項(xiàng)目引入 QTest 做單元測試雖然初期花了一些時(shí)間但后續(xù)的收益遠(yuǎn)超預(yù)期。這篇文章就圍繞 QTest 框架本身結(jié)合我在實(shí)際項(xiàng)目里的使用體驗(yàn)完整聊聊單元測試的思路、實(shí)操和避坑。如果你正打算在 Qt 項(xiàng)目里引入單元測試或者已經(jīng)在寫測試但覺得效率不高、維護(hù)成本大這篇文章應(yīng)該能給你一些直接的參考。QTest 是 Qt 官方的測試框架不算復(fù)雜但要把測試寫好、寫出價(jià)值還是有不少門道。這也是我把它拆成“工具用法”和“測試方法論”兩部分來講的原因。1. 為什么選擇 QTest 而不是其他框架先回答一個(gè)最常見的疑問Qt 項(xiàng)目做單元測試用 Google Test、Catch2 也可以為什么非要選 QTest幾個(gè)實(shí)際考量第一QTest 與 Qt 生態(tài)天然集成。Qt 的信號(hào)槽機(jī)制、事件循環(huán)、元對象系統(tǒng)等是項(xiàng)目里繞不開的基礎(chǔ)設(shè)施。QTest 對它們有原生支持比如用QSignalSpy驗(yàn)證信號(hào)是否發(fā)出、用QTest::mouseClick模擬 GUI 交互、用QVERIFY和QCOMPARE做斷言。第三方框架通常需要自己封裝這些東西反而增加復(fù)雜度。第二QTest 是 Qt 官方維護(hù)的隨 Qt 版本持續(xù)更新。項(xiàng)目用 Qt 5.12 或 Qt 6.xQTest 的頭文件和 API 基本都有良好的向前兼容性。我接觸過的幾次 Qt 升級(jí)測試代碼幾乎不需要改動(dòng)這個(gè)穩(wěn)定性很重要。第三CMake 和 qmake 都對 QTest 有直接的工程支持。通過find_package(Qt6 REQUIRED COMPONENTS Test)或 qmake 的QT testlib很快就能把測試集成為獨(dú)立的可執(zhí)行文件接入 CI持續(xù)集成非常順手。但 QTest 也有短板。一個(gè)常見吐槽是它的斷言宏不如 Google Test 豐富復(fù)雜的斷言表達(dá)式寫起來不夠優(yōu)雅另一個(gè)是 QTest 默認(rèn)要求測試類繼承QObject并用私有槽函數(shù)來組織測試用例這個(gè)模型很多人一開始不太習(xí)慣。但從團(tuán)隊(duì)協(xié)作和框架演進(jìn)角度來說QTest 帶來的穩(wěn)定性收益是遠(yuǎn)超這些小缺點(diǎn)的。值得說明的是我并不是說 Google Test 不好。如果你的項(xiàng)目還有大量非 Qt 的 C 模塊或者團(tuán)隊(duì)對某個(gè)框架已經(jīng)有了很深入的使用經(jīng)驗(yàn)混用也是常見做法。只是如果純 Qt 項(xiàng)目QTest 基本是零成本、最省心的入門選擇。我的建議是不要為了“流行”去選測試框架而是看它跟項(xiàng)目技術(shù)棧、團(tuán)隊(duì)認(rèn)知水平的匹配度。QTest 的低門檻和 Qt 深度集成能保證團(tuán)隊(duì)快速上手并長期維護(hù)。2. QTest 框架入門從最小測試用例寫起2.1 最小測試工程的目錄與構(gòu)建配置我習(xí)慣在項(xiàng)目根目錄下建一個(gè)tests文件夾每個(gè)模塊對應(yīng)一個(gè)子目錄比如tests/test_utils。這樣每個(gè)測試模塊都有獨(dú)立的可執(zhí)行文件方便在 CI 里并行跑也方便本地單獨(dú)調(diào)試。以 CMake 為例一個(gè)最小 QTest 工程的配置長這樣cmake_minimum_required(VERSION 3.16) project(TestDemo VERSION 1.0.0 LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) find_package(Qt6 REQUIRED COMPONENTS Core Test) qt_add_executable(test_utils test_utils.cpp ) target_link_libraries(test_utils PRIVATE Qt6::Core Qt6::Test ) enable_testing() add_test(NAME test_utils COMMAND test_utils)如果是 Qt 5 項(xiàng)目find_package(Qt6...)換成find_package(Qt5 REQUIRED COMPONENTS Test)并在target_link_libraries里把Qt6::Test改成Qt5::Test其余邏輯一致。enable_testing()和add_test是為了讓 CTest 能自動(dòng)發(fā)現(xiàn)并執(zhí)行測試在 CI 環(huán)節(jié)會(huì)很省事。2.2 一個(gè)完整的測試類長什么樣QTest 的核心寫法是測試類繼承QObject然后定義一系列私有槽函數(shù)每個(gè)槽函數(shù)就是一個(gè)測試用例。最基礎(chǔ)的結(jié)構(gòu)如下#include QtTest #include utils.h class TestUtils : public QObject { Q_OBJECT private slots: void initTestCase(); // 整個(gè)測試套件開始前執(zhí)行一次 void init(); // 每個(gè)測試用例執(zhí)行前執(zhí)行 void testAdd(); void testRemove(); void cleanup(); // 每個(gè)測試用例執(zhí)行后執(zhí)行 void cleanupTestCase(); // 整個(gè)測試套件結(jié)束后執(zhí)行一次 }; void TestUtils::initTestCase() { // 初始化共享資源比如數(shù)據(jù)庫連接、配置文件路徑 } void TestUtils::init() { // 每個(gè)用例開始前的數(shù)據(jù)準(zhǔn)備 } void TestUtils::testAdd() { Utils utils; QVERIFY(utils.add(key, value)); QCOMPARE(utils.value(key), QString(value)); } void TestUtils::testRemove() { Utils utils; utils.add(key, value); utils.remove(key); QVERIFY(utils.isEmpty()); } void TestUtils::cleanup() { // 清理每個(gè)用例產(chǎn)生的臨時(shí)數(shù)據(jù) } void TestUtils::cleanupTestCase() { // 釋放 initTestCase 創(chuàng)建的共享資源 } QTEST_MAIN(TestUtils) #include test_utils.moc這里有三個(gè)關(guān)鍵點(diǎn)我覺得對新手特別重要QTEST_MAIN宏會(huì)生成main函數(shù)它會(huì)依次執(zhí)行所有私有槽函數(shù)并統(tǒng)計(jì)通過/失敗結(jié)果。運(yùn)行時(shí)還可以通過-functions參數(shù)列出所有測試用例。需要#include test_utils.moc因?yàn)闇y試類繼承了QObject需要元對象編譯。遺漏這個(gè)最常見的結(jié)果就是鏈接報(bào)錯(cuò)一堆“未定義的 vtable”。每個(gè)測試用例應(yīng)該是獨(dú)立的。不要在某個(gè)用例里依賴前一個(gè)用例留下的狀態(tài)否則測試會(huì)像多米諾骨牌一樣一個(gè)掛了后面全掛而且很難排查。2.3 斷言宏如何選直接影響排查效率QTest 里出現(xiàn)頻率最高的是QVERIFY和QCOMPARE。它們的區(qū)別看起來簡單但實(shí)際使用中影響很大QVERIFY(condition)判斷條件是否為真。適合驗(yàn)證布爾結(jié)果。QCOMPARE(actual, expected)比較兩個(gè)值是否相等不相等時(shí)會(huì)在輸出里打印兩個(gè)值的具體內(nèi)容。我見過不少項(xiàng)目幾乎只用QVERIFY甚至寫出QVERIFY(a b)這樣能跑但排查體驗(yàn)很差的代碼。一旦測試失敗只能看到“FAIL! test line 42”完全不知道a是多少、b是多少。所以我的經(jīng)驗(yàn)是能用QCOMPARE的地方就不要用QVERIFY。它不僅僅是“更規(guī)范”更重要的是失敗信息可讀、可查、可快速定位。除此之外還有一些實(shí)用宏QVERIFY2(condition, message)條件不滿足時(shí)輸出自定義信息適合補(bǔ)充上下文。QTRY_VERIFY(condition)/QTRY_COMPARE(actual, expected)帶超時(shí)輪詢的斷言適合異步場景。QVERIFY_EXCEPTION_THROWN(expression, exceptionType)驗(yàn)證是否拋出指定異常。拿異步場景舉例子。假設(shè)我們要測試一個(gè)網(wǎng)絡(luò)請求是否成功返回用QVERIFY直接判斷極大概率在結(jié)果還沒回來時(shí)就失敗了。改成QTRY_VERIFY(response.received())框架會(huì)周期性檢查條件直到超時(shí)這樣既測試了功能又不至于把測試寫得無比脆弱。2.4 數(shù)據(jù)驅(qū)動(dòng)測試讓一份用例處理多組輸入很多業(yè)務(wù)函數(shù)都有“輸入多組數(shù)據(jù)期望不同結(jié)果”的特點(diǎn)。比如一個(gè)校驗(yàn)函數(shù)判斷字符串是否合法。常規(guī)寫法是為每一組數(shù)據(jù)寫一個(gè)測試函數(shù)但這種做法代碼重復(fù)嚴(yán)重加一個(gè)新數(shù)據(jù)就要加一個(gè)新函數(shù)。QTest 支持?jǐn)?shù)據(jù)驅(qū)動(dòng)測試核心思路是組合“測試函數(shù)”和“數(shù)據(jù)函數(shù)”。測試函數(shù)本身不寫死數(shù)據(jù)而是通過QFETCH取出當(dāng)前行的數(shù)據(jù)執(zhí)行斷言。class TestValidator : public QObject { Q_OBJECT private slots: void validateData(); void validate(); }; void TestValidator::validateData() { QTest::addColumnQString(input); QTest::addColumnbool(expected); QTest::newRow(合法數(shù)字) 12345 true; QTest::newRow(含字母) 12a45 false; QTest::newRow(空字符串) false; QTest::newRow(超長字符串) QString(100, 1) false; } void TestValidator::validate() { QFETCH(QString, input); QFETCH(bool, expected); Validator validator; QCOMPARE(validator.isValid(input), expected); }執(zhí)行測試時(shí)QTest 會(huì)把每組數(shù)據(jù)當(dāng)成獨(dú)立用例運(yùn)行。某個(gè)數(shù)據(jù)失敗時(shí)輸出信息會(huì)顯示“FAIL! validate(含字母)”一眼就能看出是哪個(gè)輸入引起的。我用數(shù)據(jù)驅(qū)動(dòng)測試最多的場景是配置解析、協(xié)議編解碼、邊界值校驗(yàn)。它把“數(shù)據(jù)”和“邏輯”分離得很干凈新增一組測試數(shù)據(jù)只需要在_data函數(shù)里加一行QTest::newRow不需要改動(dòng)測試邏輯本身。時(shí)間久了整個(gè)測試文件會(huì)非常清晰。3. 單元測試的設(shè)計(jì)方法先想清楚測什么再動(dòng)手寫3.1 測試代碼的定位行為契約而非實(shí)現(xiàn)細(xì)節(jié)很多人寫的單元測試實(shí)際上是“復(fù)讀機(jī)式”地跟著實(shí)現(xiàn)走。比如某個(gè)函數(shù)有三步邏輯測試就斷言每一步的中間變量。只要實(shí)現(xiàn)重構(gòu)了一點(diǎn)點(diǎn)測試就得跟著改一大片最終大家發(fā)現(xiàn)測試維護(hù)成本太高干脆不寫了。我的理解是單元測試應(yīng)該是被測模塊的“行為契約”而不是實(shí)現(xiàn)過程的“監(jiān)控錄像”。它要回答的問題是外部調(diào)用者傳入什么應(yīng)該得到什么結(jié)果、產(chǎn)生什么可觀察的行為。至于內(nèi)部是怎么算出來的不應(yīng)該被測試鎖死。舉一個(gè)實(shí)際例子。早期我給一個(gè)數(shù)據(jù)解析函數(shù)寫測試時(shí)會(huì)斷言解析過程中調(diào)用了某個(gè)私有輔助方法。后來優(yōu)化了實(shí)現(xiàn)把輔助方法刪了測試直接全掛。明明對外行為沒有變化測試卻像被判了死刑。從那以后我給自己定了一條規(guī)矩測試?yán)锉M量不 mock 內(nèi)部類不驗(yàn)證內(nèi)部調(diào)用鏈只驗(yàn)證輸入輸出和對外行為。那怎么處理外部依賴呢比如網(wǎng)絡(luò)、數(shù)據(jù)庫、時(shí)間。我的做法是給被測模塊傳入可控的接口或數(shù)據(jù)源測試時(shí)替換為樁實(shí)現(xiàn)stub而不是 Mock 掉內(nèi)部結(jié)構(gòu)。這能從設(shè)計(jì)上倒逼模塊間的解耦長期看收益非常明顯。3.2 命名規(guī)范好名字能省下大量溝通成本測試用例的命名直接決定了一個(gè)人看測試輸出時(shí)能不能立刻知道什么地方出了問題。我習(xí)慣用“被測方法_場景_期望結(jié)果”的格式全部用英文命名避免中文命名在不同編碼環(huán)境下亂碼void testSaveFile_FileNotExist_CreateNewFile(); void testSaveFile_FileExist_OverwriteContent(); void testParseConfig_InvalidContent_ReturnEmptySettings();這種命名在你寫測試報(bào)告、和同事討論失敗用例時(shí)幾乎不需要額外解釋。CI 的日志里如果出現(xiàn)testSaveFile_FileNotExist_CreateNewFile每個(gè)人都能立刻知道測試意圖。我不太建議用test1、test_function1這類命名看起來省事但三個(gè)月后連你自己都分不清每個(gè)用例在測什么。3.3 FIRST 原則好測試的五個(gè)衡量維度如果只給團(tuán)隊(duì)講一個(gè)測試設(shè)計(jì)原則我會(huì)講 FIRST 原則。它是五個(gè)單詞的縮寫原則含義不遵守時(shí)的表現(xiàn)Fast快速測試執(zhí)行速度要快跑一次測試要幾分鐘CI 排隊(duì)開發(fā)懶得跑Independent獨(dú)立用例之間互不依賴一個(gè)失敗導(dǎo)致后續(xù)一串失敗排查困難Repeatable可重復(fù)任意環(huán)境多次執(zhí)行結(jié)果一致本機(jī)能過 CI 掛掉多半是依賴環(huán)境Self-validating自驗(yàn)證測試程序自動(dòng)判斷通過/失敗靠人工看輸出信息判斷容易漏掉Timely及時(shí)測試隨生產(chǎn)代碼同步編寫功能寫完了再補(bǔ)測試補(bǔ)的時(shí)候已經(jīng)忘了細(xì)節(jié)我實(shí)際感受最深的還是第五點(diǎn)。說實(shí)話寫代碼的時(shí)候順手寫測試成本最低等項(xiàng)目上線后再補(bǔ)測試很多邊界條件根本想不起來了。我現(xiàn)在的節(jié)奏是一個(gè)模塊開發(fā)完立刻寫測試修改 bug 時(shí)先寫一個(gè)能復(fù)現(xiàn) bug 的測試再修復(fù)代碼這算是變相提醒“測試是安全網(wǎng)不是事后清單”。3.4 白盒測試視角QTest 屬于典型的白盒框架提到測試類型QTest 本質(zhì)上屬于白盒測試框架。白盒測試意味著測試者能看到被測代碼的內(nèi)部邏輯并在此基礎(chǔ)上設(shè)計(jì)用例。相比黑盒測試只關(guān)注輸入輸出白盒測試更容易定位問題、設(shè)計(jì)邊界用例。但白盒測試也有一個(gè)明顯的反噬你太清楚代碼是怎么寫的不知不覺就會(huì)把測試寫成“實(shí)現(xiàn)復(fù)讀”遇到重構(gòu)就崩。這是我在 3.1 講的“契約思維”發(fā)揮作用的地方——看得到實(shí)現(xiàn)沒問題但仍舊從外部行為角度去寫斷言。在實(shí)際項(xiàng)目中白盒測試非常適合覆蓋這些場景分支覆蓋率if-else 各個(gè)路徑、邊界值最大最小、空、超長、異常路徑錯(cuò)誤碼、異常拋出。這些用例黑盒測試不一定能想到白盒很容易。4. 實(shí)操過程信號(hào)槽測試、GUI 事件模擬與覆蓋率分析4.1 信號(hào)槽測試用 QSignalSpy 驗(yàn)證異步行為Qt 項(xiàng)目的核心特色是信號(hào)槽機(jī)制。一個(gè)按鈕點(diǎn)擊后要發(fā)射某個(gè)信號(hào)或者某個(gè)數(shù)據(jù)刷完后要通知界面刷新這些怎么測QTest 提供了一個(gè)非常實(shí)用的類QSignalSpy。它可以像探針一樣掛在某個(gè)對象的信號(hào)上等信號(hào)觸發(fā)后記錄發(fā)射時(shí)的參數(shù)。class TestController : public QObject { Q_OBJECT private slots: void testUpdateFinishedSignal(); }; void TestController::testUpdateFinishedSignal() { Controller controller; QSignalSpy spy(controller, Controller::updateFinished); controller.startUpdate(); QCOMPARE(spy.count(), 1); // 信號(hào)是否發(fā)了一次 QCOMPARE(spy.takeFirst().at(0).toBool(), true); // 參數(shù)是否符合預(yù)期 }QSignalSpy的.count()是記錄發(fā)射次數(shù).takeFirst()取出第一次發(fā)射時(shí)的參數(shù)列表。這個(gè)類能解決大部分信號(hào)相關(guān)的驗(yàn)證需求比手動(dòng) connect 一個(gè)臨時(shí)槽要簡潔得多。4.2 GUI 事件模擬把用戶交互變成可重復(fù)的測試如果你負(fù)責(zé)的模塊涉及界面交互比如點(diǎn)擊按鈕、輸入文本、選擇下拉框QTest 也提供了事件模擬能力QTest::mouseClick(button, Qt::LeftButton); QTest::keyClicks(lineEdit, hello); QTest::keyClick(comboBox, Qt::Key_Down);這些事件會(huì)被投遞到事件循環(huán)中觸發(fā)對應(yīng)的信號(hào)槽鏈路。這是 GUI 測試的基礎(chǔ)設(shè)施。但 GUI 測試有個(gè)大坑如果被測邏輯依賴窗口真正顯示出來測試可能會(huì)在 CI無顯示器環(huán)境里掛掉。我的經(jīng)驗(yàn)是把業(yè)務(wù)邏輯盡量拆到不依賴界面的類里比如按鈕的onClicked槽里只調(diào)用接口層方法這樣大多數(shù)邏輯用普通測試即可覆蓋。如果確實(shí)需要測試 Widget 的交互行為可以用QTest::mouseClick并在 CI 里配置虛擬顯示。一個(gè)非常實(shí)用的避坑點(diǎn)是不要直接訪問私有 UI 成員來設(shè)置狀態(tài)。應(yīng)該通過公共接口或QTest的事件模擬來驅(qū)動(dòng)保證測試對象的外部行為而不是被測試對象內(nèi)部的實(shí)現(xiàn)方式綁架。4.3 測試覆蓋率分析用 gcov/lcov 找到?jīng)]測到的代碼單元測試寫得再多也要問一句被測代碼到底被覆蓋了多少Q(mào)t 的 qmake/CMake 項(xiàng)目都可以配合 gcov 來生成覆蓋率報(bào)告流程并不復(fù)雜。編譯時(shí)加兩個(gè)編譯選項(xiàng)target_compile_options(test_utils PRIVATE -fprofile-arcs -ftest-coverage) target_link_options(test_utils PRIVATE -fprofile-arcs -ftest-coverage)運(yùn)行測試程序后會(huì)在目錄下生成*.gcda、*.gcno文件用lcov匯總lcov --capture --directory . --output-file coverage.info genhtml coverage.info --output-directory coverage_report瀏覽器打開coverage_report/index.html就能看每個(gè)源文件的行覆蓋率、函數(shù)覆蓋率、分支覆蓋率。覆蓋率數(shù)據(jù)如何解讀我提一點(diǎn)個(gè)人觀點(diǎn)不要盲目追求 100% 覆蓋率因?yàn)橛行┓烙源a、資源配置代碼很難被測試觸達(dá)硬寫到 100% 反而會(huì)讓測試變成“為了覆蓋率而寫”動(dòng)作走形。我的習(xí)慣是核心模塊行覆蓋率做到 70%-80%關(guān)鍵分支盡量覆蓋到一旦低于這個(gè)水準(zhǔn)就說明測試有明顯盲區(qū)需要補(bǔ)充。4.4 數(shù)據(jù)驅(qū)動(dòng)測試的進(jìn)階從表格到隨機(jī)與邊界前面提到的基礎(chǔ)數(shù)據(jù)驅(qū)動(dòng)測試用QTest::addColumn和QTest::newRow就夠了。如果需要在測試?yán)锷纱罅窟吔鐢?shù)據(jù)或隨機(jī)數(shù)據(jù)我一般會(huì)寫一個(gè)輔助函數(shù)在_data函數(shù)里批量填入void TestParser::parseData() { QTest::addColumnQString(input); QTest::addColumnQString(expected); // 固定的邊界用例 QTest::newRow(空輸入) ; QTest::newRow(純空白) ; // 批量邊界數(shù)據(jù)長度從 1 到 50 for (int len 1; len 50; len) { QString input QString(a).repeated(len); QTest::newRow(QString(長度%1).arg(len).toUtf8()) input input; } }注意newRow的序列名建議唯一否則后一條會(huì)覆蓋前一條也不要在名稱里使用中文字符時(shí)忘記轉(zhuǎn)碼。這一步在 Windows 控制臺(tái)或部分 CI 環(huán)境的日志里會(huì)出現(xiàn)編碼問題我在實(shí)測中遇到過所以現(xiàn)在統(tǒng)一用英文或拼音。5. 常見問題與排查技巧實(shí)錄5.1 鏈接錯(cuò)誤未定義的 vtable癥狀編譯輸出大量undefined reference to vtable for TestXXX。原因測試類繼承 QObject聲明了Q_OBJECT宏和私有槽函數(shù)但忘記在.cpp文件末尾#include test_xxx.moc。解決加一行#include test_xxx.moc重新編譯。如果你用的是 Qt Creator 的自動(dòng)構(gòu)建這一步一般不會(huì)漏但手動(dòng) CMake 時(shí)非常容易踩。5.2 QTEST_MAIN 與自定義 main 函數(shù)沖突如果測試過程中需要做一些非常規(guī)初始化比如設(shè)置全局的QApplication屬性有人會(huì)選擇自己寫main函數(shù)。這時(shí)需要注意int main(int argc, char *argv[]) { QApplication app(argc, argv); // 自定義初始化 TestUtils tc; QTEST_SET_MAIN_SOURCE_PATH return QTest::qExec(tc, argc, argv); } #include test_utils.moc用QTest::qExec手動(dòng)執(zhí)行測試類而不是靠QTEST_MAIN。這個(gè)方法允許你插入額外的初始化邏輯。但多數(shù)場景下我建議優(yōu)先用QTEST_MAIN保持簡單。5.3 GUI 測試卡死或無法自動(dòng)退出典型的場景是測試?yán)飐how()了一個(gè)模態(tài)對話框然后測試一直等待用戶手動(dòng)關(guān)閉CI 直接卡住直到超時(shí)。我的排查思路是檢查被測代碼是否調(diào)用了QDialog::exec()這類阻塞式調(diào)用不適合直接放進(jìn)單元測試。如果需要測試模態(tài)對話框的行為把對話框內(nèi)容拆出一個(gè)可測試的 Widget 或邏輯類避免直接調(diào)用exec()。如果真實(shí)場景逃不開exec()考慮在測試環(huán)境用非模態(tài)方式觸發(fā)或者用QTimer::singleShot模擬用戶點(diǎn)擊。5.4 斷言失敗信息不清晰用QVERIFY(a b)失敗時(shí)輸出只有條件表達(dá)式?jīng)]有實(shí)際值和期望值。換成QCOMPARE(a, b)后失敗信息里會(huì)帶上兩邊數(shù)據(jù)FAIL! : TestUtils::testAdd Compared values are not the same Actual (value(key)): hello Expected (QString(world)): world這類輸出在 CI 日志里非常救命能直接定位到具體是哪兩個(gè)值不匹配。這也是我一直強(qiáng)調(diào)優(yōu)先QCOMPARE的原因。5.5 多測試模塊如何組織一個(gè)項(xiàng)目往往幾十個(gè)模塊不可能全揉在一個(gè)測試可執(zhí)行文件里。實(shí)際工程我一般每個(gè)模塊一個(gè)測試子目錄CTest 統(tǒng)一調(diào)度ctest --test-dir build --output-on-failure如果某個(gè)模塊偶發(fā)性失敗可以單獨(dú)跑./test_utils ./test_utils -functions ./test_utils testAdd后面兩個(gè)參數(shù)分別列出所有測試用例、只跑某個(gè)指定用例本地調(diào)試效率極高。6. 我對單元測試的一些額外思考6.1 測試代碼也是代碼要同等對待我在實(shí)際工作中的一個(gè)強(qiáng)烈感受是測試代碼也是要長期維護(hù)的工程代碼不是“寫完一次就可以再也不看”的臨時(shí)腳本。它需要遵循和業(yè)務(wù)代碼同樣的可讀性標(biāo)準(zhǔn)需要代碼評(píng)審需要持續(xù)優(yōu)化。測試維護(hù)成本高的原因很多時(shí)候不是因?yàn)闇y試本身難寫而是因?yàn)樯a(chǎn)代碼可測試性太差、模塊耦合太緊、依賴隱藏太深。一個(gè)模塊如果寫起來測試很痛苦往往說明它的設(shè)計(jì)有問題。所以我在評(píng)審代碼時(shí)如果發(fā)現(xiàn)測試很難寫會(huì)反過來要求重構(gòu)生產(chǎn)代碼而不是硬寫出一個(gè)滿是 Mock 的測試。6.2 穩(wěn)定的測試比聰明的測試更值錢有些測試寫得很“聰明”能通過反射、宏技巧、各種奇技淫巧來減少代碼量。但這類測試往往對生產(chǎn)代碼的改動(dòng)特別敏感重構(gòu)一次就碎一片。我逐漸意識(shí)到測試的價(jià)值不在“寫得精巧”而在“穩(wěn)”。穩(wěn)定的意思是被測代碼行為沒變時(shí)測試永遠(yuǎn)通過行為變了測試準(zhǔn)確報(bào)警。想做到這一點(diǎn)需要刻意回避實(shí)現(xiàn)細(xì)節(jié)、保持測試結(jié)構(gòu)的常規(guī)化。少用技巧多用清晰的業(yè)務(wù)場景描述這對長期維護(hù)是巨大幫助。6.3 覆蓋率是結(jié)果不是目標(biāo)覆蓋率數(shù)據(jù)是一個(gè)參考指標(biāo)不是發(fā)獎(jiǎng)金的標(biāo)準(zhǔn)。我見過團(tuán)隊(duì)為了把覆蓋率從 80% 提到 90%寫了很多只調(diào)用函數(shù)但不驗(yàn)證結(jié)果的測試行覆蓋率是上去了但測試對行為的守護(hù)幾乎沒有意義。我的做法是把覆蓋率報(bào)告當(dāng)作“發(fā)現(xiàn)測試盲區(qū)”的工具。比如看到某個(gè)核心解析函數(shù)分支覆蓋率只有 30%就會(huì)去想想這里是不是有沒被覆蓋的邊界條件需要補(bǔ)測試。方向是從業(yè)務(wù)風(fēng)險(xiǎn)出發(fā)補(bǔ)測試而不是為了數(shù)字去堆用例?；氐介_頭的問題QTest 能解決什么它能讓你在提交代碼前快速發(fā)現(xiàn)回歸問題能讓你重構(gòu)時(shí)更有底氣能讓團(tuán)隊(duì)協(xié)作時(shí)不必?fù)?dān)心“我改了這個(gè)文件會(huì)不會(huì)導(dǎo)致別人功能掛掉”。但這一切的前提是你愿意花時(shí)間把測試寫好、把測試方法論建起來。如果你剛開始接觸 QTest不用想著一步到位。先在項(xiàng)目里挑一個(gè)相對獨(dú)立的核心模塊寫十幾二十個(gè)基礎(chǔ)用例跑起來接入 CI。等習(xí)慣了這種模式再逐步鋪開性價(jià)比會(huì)更好。就我個(gè)人的體會(huì)來說單元測試帶來的最大變化不是 Bug 變少了而是心態(tài)變穩(wěn)了——你知道自己改過的東西是被驗(yàn)證過的這個(gè)踏實(shí)感是其他工具很難替代的。 QTest單元測試框架實(shí)戰(zhàn)：從入門到工程化應(yīng)用與設(shè)計(jì)方法
從實(shí)際項(xiàng)目經(jīng)驗(yàn)談 QTest 單元測試框架的應(yīng)用與設(shè)計(jì)思路做 Qt 開發(fā)久了尤其在項(xiàng)目規(guī)模變大、多人協(xié)作的節(jié)奏下一定會(huì)有這樣的時(shí)刻改了一個(gè)看似無關(guān)緊要的接口跑起來發(fā)現(xiàn)完全不是想的那樣甚至在老功能里莫名其妙引入了回歸問題。這個(gè)痛點(diǎn)我太熟悉了。后來項(xiàng)目引入 QTest 做單元測試雖然初期花了一些時(shí)間但后續(xù)的收益遠(yuǎn)超預(yù)期。這篇文章就圍繞 QTest 框架本身結(jié)合我在實(shí)際項(xiàng)目里的使用體驗(yàn)完整聊聊單元測試的思路、實(shí)操和避坑。如果你正打算在 Qt 項(xiàng)目里引入單元測試或者已經(jīng)在寫測試但覺得效率不高、維護(hù)成本大這篇文章應(yīng)該能給你一些直接的參考。QTest 是 Qt 官方的測試框架不算復(fù)雜但要把測試寫好、寫出價(jià)值還是有不少門道。這也是我把它拆成“工具用法”和“測試方法論”兩部分來講的原因。1. 為什么選擇 QTest 而不是其他框架先回答一個(gè)最常見的疑問Qt 項(xiàng)目做單元測試用 Google Test、Catch2 也可以為什么非要選 QTest幾個(gè)實(shí)際考量第一QTest 與 Qt 生態(tài)天然集成。Qt 的信號(hào)槽機(jī)制、事件循環(huán)、元對象系統(tǒng)等是項(xiàng)目里繞不開的基礎(chǔ)設(shè)施。QTest 對它們有原生支持比如用QSignalSpy驗(yàn)證信號(hào)是否發(fā)出、用QTest::mouseClick模擬 GUI 交互、用QVERIFY和QCOMPARE做斷言。第三方框架通常需要自己封裝這些東西反而增加復(fù)雜度。第二QTest 是 Qt 官方維護(hù)的隨 Qt 版本持續(xù)更新。項(xiàng)目用 Qt 5.12 或 Qt 6.xQTest 的頭文件和 API 基本都有良好的向前兼容性。我接觸過的幾次 Qt 升級(jí)測試代碼幾乎不需要改動(dòng)這個(gè)穩(wěn)定性很重要。第三CMake 和 qmake 都對 QTest 有直接的工程支持。通過find_package(Qt6 REQUIRED COMPONENTS Test)或 qmake 的QT testlib很快就能把測試集成為獨(dú)立的可執(zhí)行文件接入 CI持續(xù)集成非常順手。但 QTest 也有短板。一個(gè)常見吐槽是它的斷言宏不如 Google Test 豐富復(fù)雜的斷言表達(dá)式寫起來不夠優(yōu)雅另一個(gè)是 QTest 默認(rèn)要求測試類繼承QObject并用私有槽函數(shù)來組織測試用例這個(gè)模型很多人一開始不太習(xí)慣。但從團(tuán)隊(duì)協(xié)作和框架演進(jìn)角度來說QTest 帶來的穩(wěn)定性收益是遠(yuǎn)超這些小缺點(diǎn)的。值得說明的是我并不是說 Google Test 不好。如果你的項(xiàng)目還有大量非 Qt 的 C 模塊或者團(tuán)隊(duì)對某個(gè)框架已經(jīng)有了很深入的使用經(jīng)驗(yàn)混用也是常見做法。只是如果純 Qt 項(xiàng)目QTest 基本是零成本、最省心的入門選擇。我的建議是不要為了“流行”去選測試框架而是看它跟項(xiàng)目技術(shù)棧、團(tuán)隊(duì)認(rèn)知水平的匹配度。QTest 的低門檻和 Qt 深度集成能保證團(tuán)隊(duì)快速上手并長期維護(hù)。2. QTest 框架入門從最小測試用例寫起2.1 最小測試工程的目錄與構(gòu)建配置我習(xí)慣在項(xiàng)目根目錄下建一個(gè)tests文件夾每個(gè)模塊對應(yīng)一個(gè)子目錄比如tests/test_utils。這樣每個(gè)測試模塊都有獨(dú)立的可執(zhí)行文件方便在 CI 里并行跑也方便本地單獨(dú)調(diào)試。以 CMake 為例一個(gè)最小 QTest 工程的配置長這樣cmake_minimum_required(VERSION 3.16) project(TestDemo VERSION 1.0.0 LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) find_package(Qt6 REQUIRED COMPONENTS Core Test) qt_add_executable(test_utils test_utils.cpp ) target_link_libraries(test_utils PRIVATE Qt6::Core Qt6::Test ) enable_testing() add_test(NAME test_utils COMMAND test_utils)如果是 Qt 5 項(xiàng)目find_package(Qt6...)換成find_package(Qt5 REQUIRED COMPONENTS Test)并在target_link_libraries里把Qt6::Test改成Qt5::Test其余邏輯一致。enable_testing()和add_test是為了讓 CTest 能自動(dòng)發(fā)現(xiàn)并執(zhí)行測試在 CI 環(huán)節(jié)會(huì)很省事。2.2 一個(gè)完整的測試類長什么樣QTest 的核心寫法是測試類繼承QObject然后定義一系列私有槽函數(shù)每個(gè)槽函數(shù)就是一個(gè)測試用例。最基礎(chǔ)的結(jié)構(gòu)如下#include QtTest #include utils.h class TestUtils : public QObject { Q_OBJECT private slots: void initTestCase(); // 整個(gè)測試套件開始前執(zhí)行一次 void init(); // 每個(gè)測試用例執(zhí)行前執(zhí)行 void testAdd(); void testRemove(); void cleanup(); // 每個(gè)測試用例執(zhí)行后執(zhí)行 void cleanupTestCase(); // 整個(gè)測試套件結(jié)束后執(zhí)行一次 }; void TestUtils::initTestCase() { // 初始化共享資源比如數(shù)據(jù)庫連接、配置文件路徑 } void TestUtils::init() { // 每個(gè)用例開始前的數(shù)據(jù)準(zhǔn)備 } void TestUtils::testAdd() { Utils utils; QVERIFY(utils.add(key, value)); QCOMPARE(utils.value(key), QString(value)); } void TestUtils::testRemove() { Utils utils; utils.add(key, value); utils.remove(key); QVERIFY(utils.isEmpty()); } void TestUtils::cleanup() { // 清理每個(gè)用例產(chǎn)生的臨時(shí)數(shù)據(jù) } void TestUtils::cleanupTestCase() { // 釋放 initTestCase 創(chuàng)建的共享資源 } QTEST_MAIN(TestUtils) #include test_utils.moc這里有三個(gè)關(guān)鍵點(diǎn)我覺得對新手特別重要QTEST_MAIN宏會(huì)生成main函數(shù)它會(huì)依次執(zhí)行所有私有槽函數(shù)并統(tǒng)計(jì)通過/失敗結(jié)果。運(yùn)行時(shí)還可以通過-functions參數(shù)列出所有測試用例。需要#include test_utils.moc因?yàn)闇y試類繼承了QObject需要元對象編譯。遺漏這個(gè)最常見的結(jié)果就是鏈接報(bào)錯(cuò)一堆“未定義的 vtable”。每個(gè)測試用例應(yīng)該是獨(dú)立的。不要在某個(gè)用例里依賴前一個(gè)用例留下的狀態(tài)否則測試會(huì)像多米諾骨牌一樣一個(gè)掛了后面全掛而且很難排查。2.3 斷言宏如何選直接影響排查效率QTest 里出現(xiàn)頻率最高的是QVERIFY和QCOMPARE。它們的區(qū)別看起來簡單但實(shí)際使用中影響很大QVERIFY(condition)判斷條件是否為真。適合驗(yàn)證布爾結(jié)果。QCOMPARE(actual, expected)比較兩個(gè)值是否相等不相等時(shí)會(huì)在輸出里打印兩個(gè)值的具體內(nèi)容。我見過不少項(xiàng)目幾乎只用QVERIFY甚至寫出QVERIFY(a b)這樣能跑但排查體驗(yàn)很差的代碼。一旦測試失敗只能看到“FAIL! test line 42”完全不知道a是多少、b是多少。所以我的經(jīng)驗(yàn)是能用QCOMPARE的地方就不要用QVERIFY。它不僅僅是“更規(guī)范”更重要的是失敗信息可讀、可查、可快速定位。除此之外還有一些實(shí)用宏QVERIFY2(condition, message)條件不滿足時(shí)輸出自定義信息適合補(bǔ)充上下文。QTRY_VERIFY(condition)/QTRY_COMPARE(actual, expected)帶超時(shí)輪詢的斷言適合異步場景。QVERIFY_EXCEPTION_THROWN(expression, exceptionType)驗(yàn)證是否拋出指定異常。拿異步場景舉例子。假設(shè)我們要測試一個(gè)網(wǎng)絡(luò)請求是否成功返回用QVERIFY直接判斷極大概率在結(jié)果還沒回來時(shí)就失敗了。改成QTRY_VERIFY(response.received())框架會(huì)周期性檢查條件直到超時(shí)這樣既測試了功能又不至于把測試寫得無比脆弱。2.4 數(shù)據(jù)驅(qū)動(dòng)測試讓一份用例處理多組輸入很多業(yè)務(wù)函數(shù)都有“輸入多組數(shù)據(jù)期望不同結(jié)果”的特點(diǎn)。比如一個(gè)校驗(yàn)函數(shù)判斷字符串是否合法。常規(guī)寫法是為每一組數(shù)據(jù)寫一個(gè)測試函數(shù)但這種做法代碼重復(fù)嚴(yán)重加一個(gè)新數(shù)據(jù)就要加一個(gè)新函數(shù)。QTest 支持?jǐn)?shù)據(jù)驅(qū)動(dòng)測試核心思路是組合“測試函數(shù)”和“數(shù)據(jù)函數(shù)”。測試函數(shù)本身不寫死數(shù)據(jù)而是通過QFETCH取出當(dāng)前行的數(shù)據(jù)執(zhí)行斷言。class TestValidator : public QObject { Q_OBJECT private slots: void validateData(); void validate(); }; void TestValidator::validateData() { QTest::addColumnQString(input); QTest::addColumnbool(expected); QTest::newRow(合法數(shù)字) 12345 true; QTest::newRow(含字母) 12a45 false; QTest::newRow(空字符串) false; QTest::newRow(超長字符串) QString(100, 1) false; } void TestValidator::validate() { QFETCH(QString, input); QFETCH(bool, expected); Validator validator; QCOMPARE(validator.isValid(input), expected); }執(zhí)行測試時(shí)QTest 會(huì)把每組數(shù)據(jù)當(dāng)成獨(dú)立用例運(yùn)行。某個(gè)數(shù)據(jù)失敗時(shí)輸出信息會(huì)顯示“FAIL! validate(含字母)”一眼就能看出是哪個(gè)輸入引起的。我用數(shù)據(jù)驅(qū)動(dòng)測試最多的場景是配置解析、協(xié)議編解碼、邊界值校驗(yàn)。它把“數(shù)據(jù)”和“邏輯”分離得很干凈新增一組測試數(shù)據(jù)只需要在_data函數(shù)里加一行QTest::newRow不需要改動(dòng)測試邏輯本身。時(shí)間久了整個(gè)測試文件會(huì)非常清晰。3. 單元測試的設(shè)計(jì)方法先想清楚測什么再動(dòng)手寫3.1 測試代碼的定位行為契約而非實(shí)現(xiàn)細(xì)節(jié)很多人寫的單元測試實(shí)際上是“復(fù)讀機(jī)式”地跟著實(shí)現(xiàn)走。比如某個(gè)函數(shù)有三步邏輯測試就斷言每一步的中間變量。只要實(shí)現(xiàn)重構(gòu)了一點(diǎn)點(diǎn)測試就得跟著改一大片最終大家發(fā)現(xiàn)測試維護(hù)成本太高干脆不寫了。我的理解是單元測試應(yīng)該是被測模塊的“行為契約”而不是實(shí)現(xiàn)過程的“監(jiān)控錄像”。它要回答的問題是外部調(diào)用者傳入什么應(yīng)該得到什么結(jié)果、產(chǎn)生什么可觀察的行為。至于內(nèi)部是怎么算出來的不應(yīng)該被測試鎖死。舉一個(gè)實(shí)際例子。早期我給一個(gè)數(shù)據(jù)解析函數(shù)寫測試時(shí)會(huì)斷言解析過程中調(diào)用了某個(gè)私有輔助方法。后來優(yōu)化了實(shí)現(xiàn)把輔助方法刪了測試直接全掛。明明對外行為沒有變化測試卻像被判了死刑。從那以后我給自己定了一條規(guī)矩測試?yán)锉M量不 mock 內(nèi)部類不驗(yàn)證內(nèi)部調(diào)用鏈只驗(yàn)證輸入輸出和對外行為。那怎么處理外部依賴呢比如網(wǎng)絡(luò)、數(shù)據(jù)庫、時(shí)間。我的做法是給被測模塊傳入可控的接口或數(shù)據(jù)源測試時(shí)替換為樁實(shí)現(xiàn)stub而不是 Mock 掉內(nèi)部結(jié)構(gòu)。這能從設(shè)計(jì)上倒逼模塊間的解耦長期看收益非常明顯。3.2 命名規(guī)范好名字能省下大量溝通成本測試用例的命名直接決定了一個(gè)人看測試輸出時(shí)能不能立刻知道什么地方出了問題。我習(xí)慣用“被測方法_場景_期望結(jié)果”的格式全部用英文命名避免中文命名在不同編碼環(huán)境下亂碼void testSaveFile_FileNotExist_CreateNewFile(); void testSaveFile_FileExist_OverwriteContent(); void testParseConfig_InvalidContent_ReturnEmptySettings();這種命名在你寫測試報(bào)告、和同事討論失敗用例時(shí)幾乎不需要額外解釋。CI 的日志里如果出現(xiàn)testSaveFile_FileNotExist_CreateNewFile每個(gè)人都能立刻知道測試意圖。我不太建議用test1、test_function1這類命名看起來省事但三個(gè)月后連你自己都分不清每個(gè)用例在測什么。3.3 FIRST 原則好測試的五個(gè)衡量維度如果只給團(tuán)隊(duì)講一個(gè)測試設(shè)計(jì)原則我會(huì)講 FIRST 原則。它是五個(gè)單詞的縮寫原則含義不遵守時(shí)的表現(xiàn)Fast快速測試執(zhí)行速度要快跑一次測試要幾分鐘CI 排隊(duì)開發(fā)懶得跑Independent獨(dú)立用例之間互不依賴一個(gè)失敗導(dǎo)致后續(xù)一串失敗排查困難Repeatable可重復(fù)任意環(huán)境多次執(zhí)行結(jié)果一致本機(jī)能過 CI 掛掉多半是依賴環(huán)境Self-validating自驗(yàn)證測試程序自動(dòng)判斷通過/失敗靠人工看輸出信息判斷容易漏掉Timely及時(shí)測試隨生產(chǎn)代碼同步編寫功能寫完了再補(bǔ)測試補(bǔ)的時(shí)候已經(jīng)忘了細(xì)節(jié)我實(shí)際感受最深的還是第五點(diǎn)。說實(shí)話寫代碼的時(shí)候順手寫測試成本最低等項(xiàng)目上線后再補(bǔ)測試很多邊界條件根本想不起來了。我現(xiàn)在的節(jié)奏是一個(gè)模塊開發(fā)完立刻寫測試修改 bug 時(shí)先寫一個(gè)能復(fù)現(xiàn) bug 的測試再修復(fù)代碼這算是變相提醒“測試是安全網(wǎng)不是事后清單”。3.4 白盒測試視角QTest 屬于典型的白盒框架提到測試類型QTest 本質(zhì)上屬于白盒測試框架。白盒測試意味著測試者能看到被測代碼的內(nèi)部邏輯并在此基礎(chǔ)上設(shè)計(jì)用例。相比黑盒測試只關(guān)注輸入輸出白盒測試更容易定位問題、設(shè)計(jì)邊界用例。但白盒測試也有一個(gè)明顯的反噬你太清楚代碼是怎么寫的不知不覺就會(huì)把測試寫成“實(shí)現(xiàn)復(fù)讀”遇到重構(gòu)就崩。這是我在 3.1 講的“契約思維”發(fā)揮作用的地方——看得到實(shí)現(xiàn)沒問題但仍舊從外部行為角度去寫斷言。在實(shí)際項(xiàng)目中白盒測試非常適合覆蓋這些場景分支覆蓋率if-else 各個(gè)路徑、邊界值最大最小、空、超長、異常路徑錯(cuò)誤碼、異常拋出。這些用例黑盒測試不一定能想到白盒很容易。4. 實(shí)操過程信號(hào)槽測試、GUI 事件模擬與覆蓋率分析4.1 信號(hào)槽測試用 QSignalSpy 驗(yàn)證異步行為Qt 項(xiàng)目的核心特色是信號(hào)槽機(jī)制。一個(gè)按鈕點(diǎn)擊后要發(fā)射某個(gè)信號(hào)或者某個(gè)數(shù)據(jù)刷完后要通知界面刷新這些怎么測QTest 提供了一個(gè)非常實(shí)用的類QSignalSpy。它可以像探針一樣掛在某個(gè)對象的信號(hào)上等信號(hào)觸發(fā)后記錄發(fā)射時(shí)的參數(shù)。class TestController : public QObject { Q_OBJECT private slots: void testUpdateFinishedSignal(); }; void TestController::testUpdateFinishedSignal() { Controller controller; QSignalSpy spy(controller, Controller::updateFinished); controller.startUpdate(); QCOMPARE(spy.count(), 1); // 信號(hào)是否發(fā)了一次 QCOMPARE(spy.takeFirst().at(0).toBool(), true); // 參數(shù)是否符合預(yù)期 }QSignalSpy的.count()是記錄發(fā)射次數(shù).takeFirst()取出第一次發(fā)射時(shí)的參數(shù)列表。這個(gè)類能解決大部分信號(hào)相關(guān)的驗(yàn)證需求比手動(dòng) connect 一個(gè)臨時(shí)槽要簡潔得多。4.2 GUI 事件模擬把用戶交互變成可重復(fù)的測試如果你負(fù)責(zé)的模塊涉及界面交互比如點(diǎn)擊按鈕、輸入文本、選擇下拉框QTest 也提供了事件模擬能力QTest::mouseClick(button, Qt::LeftButton); QTest::keyClicks(lineEdit, hello); QTest::keyClick(comboBox, Qt::Key_Down);這些事件會(huì)被投遞到事件循環(huán)中觸發(fā)對應(yīng)的信號(hào)槽鏈路。這是 GUI 測試的基礎(chǔ)設(shè)施。但 GUI 測試有個(gè)大坑如果被測邏輯依賴窗口真正顯示出來測試可能會(huì)在 CI無顯示器環(huán)境里掛掉。我的經(jīng)驗(yàn)是把業(yè)務(wù)邏輯盡量拆到不依賴界面的類里比如按鈕的onClicked槽里只調(diào)用接口層方法這樣大多數(shù)邏輯用普通測試即可覆蓋。如果確實(shí)需要測試 Widget 的交互行為可以用QTest::mouseClick并在 CI 里配置虛擬顯示。一個(gè)非常實(shí)用的避坑點(diǎn)是不要直接訪問私有 UI 成員來設(shè)置狀態(tài)。應(yīng)該通過公共接口或QTest的事件模擬來驅(qū)動(dòng)保證測試對象的外部行為而不是被測試對象內(nèi)部的實(shí)現(xiàn)方式綁架。4.3 測試覆蓋率分析用 gcov/lcov 找到?jīng)]測到的代碼單元測試寫得再多也要問一句被測代碼到底被覆蓋了多少Q(mào)t 的 qmake/CMake 項(xiàng)目都可以配合 gcov 來生成覆蓋率報(bào)告流程并不復(fù)雜。編譯時(shí)加兩個(gè)編譯選項(xiàng)target_compile_options(test_utils PRIVATE -fprofile-arcs -ftest-coverage) target_link_options(test_utils PRIVATE -fprofile-arcs -ftest-coverage)運(yùn)行測試程序后會(huì)在目錄下生成*.gcda、*.gcno文件用lcov匯總lcov --capture --directory . --output-file coverage.info genhtml coverage.info --output-directory coverage_report瀏覽器打開coverage_report/index.html就能看每個(gè)源文件的行覆蓋率、函數(shù)覆蓋率、分支覆蓋率。覆蓋率數(shù)據(jù)如何解讀我提一點(diǎn)個(gè)人觀點(diǎn)不要盲目追求 100% 覆蓋率因?yàn)橛行┓烙源a、資源配置代碼很難被測試觸達(dá)硬寫到 100% 反而會(huì)讓測試變成“為了覆蓋率而寫”動(dòng)作走形。我的習(xí)慣是核心模塊行覆蓋率做到 70%-80%關(guān)鍵分支盡量覆蓋到一旦低于這個(gè)水準(zhǔn)就說明測試有明顯盲區(qū)需要補(bǔ)充。4.4 數(shù)據(jù)驅(qū)動(dòng)測試的進(jìn)階從表格到隨機(jī)與邊界前面提到的基礎(chǔ)數(shù)據(jù)驅(qū)動(dòng)測試用QTest::addColumn和QTest::newRow就夠了。如果需要在測試?yán)锷纱罅窟吔鐢?shù)據(jù)或隨機(jī)數(shù)據(jù)我一般會(huì)寫一個(gè)輔助函數(shù)在_data函數(shù)里批量填入void TestParser::parseData() { QTest::addColumnQString(input); QTest::addColumnQString(expected); // 固定的邊界用例 QTest::newRow(空輸入) ; QTest::newRow(純空白) ; // 批量邊界數(shù)據(jù)長度從 1 到 50 for (int len 1; len 50; len) { QString input QString(a).repeated(len); QTest::newRow(QString(長度%1).arg(len).toUtf8()) input input; } }注意newRow的序列名建議唯一否則后一條會(huì)覆蓋前一條也不要在名稱里使用中文字符時(shí)忘記轉(zhuǎn)碼。這一步在 Windows 控制臺(tái)或部分 CI 環(huán)境的日志里會(huì)出現(xiàn)編碼問題我在實(shí)測中遇到過所以現(xiàn)在統(tǒng)一用英文或拼音。5. 常見問題與排查技巧實(shí)錄5.1 鏈接錯(cuò)誤未定義的 vtable癥狀編譯輸出大量undefined reference to vtable for TestXXX。原因測試類繼承 QObject聲明了Q_OBJECT宏和私有槽函數(shù)但忘記在.cpp文件末尾#include test_xxx.moc。解決加一行#include test_xxx.moc重新編譯。如果你用的是 Qt Creator 的自動(dòng)構(gòu)建這一步一般不會(huì)漏但手動(dòng) CMake 時(shí)非常容易踩。5.2 QTEST_MAIN 與自定義 main 函數(shù)沖突如果測試過程中需要做一些非常規(guī)初始化比如設(shè)置全局的QApplication屬性有人會(huì)選擇自己寫main函數(shù)。這時(shí)需要注意int main(int argc, char *argv[]) { QApplication app(argc, argv); // 自定義初始化 TestUtils tc; QTEST_SET_MAIN_SOURCE_PATH return QTest::qExec(tc, argc, argv); } #include test_utils.moc用QTest::qExec手動(dòng)執(zhí)行測試類而不是靠QTEST_MAIN。這個(gè)方法允許你插入額外的初始化邏輯。但多數(shù)場景下我建議優(yōu)先用QTEST_MAIN保持簡單。5.3 GUI 測試卡死或無法自動(dòng)退出典型的場景是測試?yán)飐how()了一個(gè)模態(tài)對話框然后測試一直等待用戶手動(dòng)關(guān)閉CI 直接卡住直到超時(shí)。我的排查思路是檢查被測代碼是否調(diào)用了QDialog::exec()這類阻塞式調(diào)用不適合直接放進(jìn)單元測試。如果需要測試模態(tài)對話框的行為把對話框內(nèi)容拆出一個(gè)可測試的 Widget 或邏輯類避免直接調(diào)用exec()。如果真實(shí)場景逃不開exec()考慮在測試環(huán)境用非模態(tài)方式觸發(fā)或者用QTimer::singleShot模擬用戶點(diǎn)擊。5.4 斷言失敗信息不清晰用QVERIFY(a b)失敗時(shí)輸出只有條件表達(dá)式?jīng)]有實(shí)際值和期望值。換成QCOMPARE(a, b)后失敗信息里會(huì)帶上兩邊數(shù)據(jù)FAIL! : TestUtils::testAdd Compared values are not the same Actual (value(key)): hello Expected (QString(world)): world這類輸出在 CI 日志里非常救命能直接定位到具體是哪兩個(gè)值不匹配。這也是我一直強(qiáng)調(diào)優(yōu)先QCOMPARE的原因。5.5 多測試模塊如何組織一個(gè)項(xiàng)目往往幾十個(gè)模塊不可能全揉在一個(gè)測試可執(zhí)行文件里。實(shí)際工程我一般每個(gè)模塊一個(gè)測試子目錄CTest 統(tǒng)一調(diào)度ctest --test-dir build --output-on-failure如果某個(gè)模塊偶發(fā)性失敗可以單獨(dú)跑./test_utils ./test_utils -functions ./test_utils testAdd后面兩個(gè)參數(shù)分別列出所有測試用例、只跑某個(gè)指定用例本地調(diào)試效率極高。6. 我對單元測試的一些額外思考6.1 測試代碼也是代碼要同等對待我在實(shí)際工作中的一個(gè)強(qiáng)烈感受是測試代碼也是要長期維護(hù)的工程代碼不是“寫完一次就可以再也不看”的臨時(shí)腳本。它需要遵循和業(yè)務(wù)代碼同樣的可讀性標(biāo)準(zhǔn)需要代碼評(píng)審需要持續(xù)優(yōu)化。測試維護(hù)成本高的原因很多時(shí)候不是因?yàn)闇y試本身難寫而是因?yàn)樯a(chǎn)代碼可測試性太差、模塊耦合太緊、依賴隱藏太深。一個(gè)模塊如果寫起來測試很痛苦往往說明它的設(shè)計(jì)有問題。所以我在評(píng)審代碼時(shí)如果發(fā)現(xiàn)測試很難寫會(huì)反過來要求重構(gòu)生產(chǎn)代碼而不是硬寫出一個(gè)滿是 Mock 的測試。6.2 穩(wěn)定的測試比聰明的測試更值錢有些測試寫得很“聰明”能通過反射、宏技巧、各種奇技淫巧來減少代碼量。但這類測試往往對生產(chǎn)代碼的改動(dòng)特別敏感重構(gòu)一次就碎一片。我逐漸意識(shí)到測試的價(jià)值不在“寫得精巧”而在“穩(wěn)”。穩(wěn)定的意思是被測代碼行為沒變時(shí)測試永遠(yuǎn)通過行為變了測試準(zhǔn)確報(bào)警。想做到這一點(diǎn)需要刻意回避實(shí)現(xiàn)細(xì)節(jié)、保持測試結(jié)構(gòu)的常規(guī)化。少用技巧多用清晰的業(yè)務(wù)場景描述這對長期維護(hù)是巨大幫助。6.3 覆蓋率是結(jié)果不是目標(biāo)覆蓋率數(shù)據(jù)是一個(gè)參考指標(biāo)不是發(fā)獎(jiǎng)金的標(biāo)準(zhǔn)。我見過團(tuán)隊(duì)為了把覆蓋率從 80% 提到 90%寫了很多只調(diào)用函數(shù)但不驗(yàn)證結(jié)果的測試行覆蓋率是上去了但測試對行為的守護(hù)幾乎沒有意義。我的做法是把覆蓋率報(bào)告當(dāng)作“發(fā)現(xiàn)測試盲區(qū)”的工具。比如看到某個(gè)核心解析函數(shù)分支覆蓋率只有 30%就會(huì)去想想這里是不是有沒被覆蓋的邊界條件需要補(bǔ)測試。方向是從業(yè)務(wù)風(fēng)險(xiǎn)出發(fā)補(bǔ)測試而不是為了數(shù)字去堆用例?；氐介_頭的問題QTest 能解決什么它能讓你在提交代碼前快速發(fā)現(xiàn)回歸問題能讓你重構(gòu)時(shí)更有底氣能讓團(tuán)隊(duì)協(xié)作時(shí)不必?fù)?dān)心“我改了這個(gè)文件會(huì)不會(huì)導(dǎo)致別人功能掛掉”。但這一切的前提是你愿意花時(shí)間把測試寫好、把測試方法論建起來。如果你剛開始接觸 QTest不用想著一步到位。先在項(xiàng)目里挑一個(gè)相對獨(dú)立的核心模塊寫十幾二十個(gè)基礎(chǔ)用例跑起來接入 CI。等習(xí)慣了這種模式再逐步鋪開性價(jià)比會(huì)更好。就我個(gè)人的體會(huì)來說單元測試帶來的最大變化不是 Bug 變少了而是心態(tài)變穩(wěn)了——你知道自己改過的東西是被驗(yàn)證過的這個(gè)踏實(shí)感是其他工具很難替代的。