1. 項(xiàng)目概述為什么我們需要一個(gè)GoogleTest與CMake的實(shí)踐示例如果你是一名C開發(fā)者無論你是剛?cè)胄械男率诌€是已經(jīng)寫了幾年業(yè)務(wù)邏輯的老手遲早有一天你會被問到“你的代碼有單元測試嗎” 這個(gè)問題背后是軟件質(zhì)量、重構(gòu)信心和團(tuán)隊(duì)協(xié)作效率的基石。而當(dāng)我們談?wù)揅的單元測試時(shí)GoogleTest簡稱gtest幾乎是繞不開的名字它強(qiáng)大、穩(wěn)定是Google內(nèi)部廣泛使用的測試框架。但另一個(gè)更現(xiàn)實(shí)的問題是如何把它優(yōu)雅地、可維護(hù)地集成到你的項(xiàng)目構(gòu)建流程里這時(shí)CMake就登場了。我見過太多項(xiàng)目測試代碼的構(gòu)建是一團(tuán)亂麻。有的直接把gtest源碼拖進(jìn)項(xiàng)目目錄有的寫死絕對路徑有的甚至手動編譯gtest庫再配置一堆復(fù)雜的鏈接器選項(xiàng)。這些做法在項(xiàng)目初期或許能跑起來但隨著項(xiàng)目迭代、團(tuán)隊(duì)人員變動、跨平臺需求出現(xiàn)維護(hù)成本會指數(shù)級上升。最終測試代碼本身成了“不敢碰”的遺留代碼。這個(gè)開源示例項(xiàng)目就是為了解決這個(gè)“最后一公里”的問題。它不是一個(gè)簡單的“Hello World”測試而是一個(gè)完整的、生產(chǎn)可用的、基于現(xiàn)代CMake最佳實(shí)踐的單元測試集成樣板。它展示了如何用CMake的FetchContent模塊自動下載和管理gtest依賴如何組織測試目錄結(jié)構(gòu)如何編寫清晰有效的測試用例以及如何一鍵運(yùn)行所有測試并生成報(bào)告。無論你是在啟動一個(gè)新項(xiàng)目還是打算為一個(gè)遺留項(xiàng)目引入單元測試這個(gè)示例都能給你一個(gè)可以直接復(fù)制粘貼的起點(diǎn)讓你避開我當(dāng)年踩過的所有坑。2. 核心設(shè)計(jì)思路現(xiàn)代CMake與自動化依賴管理2.1 為什么選擇“FetchContent”而非手動管理在過去集成第三方庫如gtest常見做法無外乎兩種1將源碼作為子模塊git submodule放入項(xiàng)目2預(yù)編譯成庫文件讓開發(fā)者自行安裝到系統(tǒng)路徑。第一種方式會讓你的倉庫體積膨脹且版本更新麻煩第二種方式則對開發(fā)環(huán)境有強(qiáng)要求“在我機(jī)器上能跑”的噩夢由此開始?，F(xiàn)代CMake3.11版本及以上提供的FetchContent模塊提供了一種更優(yōu)雅的解決方案它在配置階段configure time動態(tài)地從網(wǎng)絡(luò)如GitHub獲取依賴項(xiàng)的源碼然后像處理項(xiàng)目內(nèi)子目錄一樣處理它。這樣做的好處顯而易見環(huán)境無關(guān)性任何克隆了你項(xiàng)目的開發(fā)者只需要有CMake、編譯器和網(wǎng)絡(luò)就能一鍵構(gòu)建包括測試依賴。無需手動安裝gtest。版本鎖定你可以在CMakeLists.txt中精確指定依賴的版本或提交哈希確保團(tuán)隊(duì)所有成員以及CI/CD服務(wù)器使用完全一致的測試框架版本避免因版本差異導(dǎo)致的測試行為不一致。干凈的項(xiàng)目結(jié)構(gòu)你的項(xiàng)目倉庫里不再需要包含第三方庫的源碼保持專注和輕量。在這個(gè)示例項(xiàng)目中我們正是采用了FetchContent來引入GoogleTest。這是當(dāng)前C生態(tài)中管理此類開發(fā)依賴的事實(shí)標(biāo)準(zhǔn)做法。2.2 項(xiàng)目結(jié)構(gòu)設(shè)計(jì)分離關(guān)注點(diǎn)一個(gè)清晰的目錄結(jié)構(gòu)是項(xiàng)目可維護(hù)性的第一步。示例項(xiàng)目的結(jié)構(gòu)通常如下所示my_project/ ├── CMakeLists.txt # 項(xiàng)目根CMake配置 ├── include/ # 公共頭文件 │ └── my_math.h ├── src/ # 項(xiàng)目源碼 │ ├── CMakeLists.txt │ └── my_math.cpp └── tests/ # 測試代碼目錄 ├── CMakeLists.txt # 測試專用的CMake配置 └── test_my_math.cpp # 具體的測試用例文件關(guān)鍵點(diǎn)解析src/和tests/目錄下各有自己的CMakeLists.txt。這符合CMake的“模塊化”思想根文件通過add_subdirectory()來組織它們。產(chǎn)品代碼src和測試代碼tests物理分離。這避免了測試代碼被意外打包到發(fā)布版本中也使得概念上更加清晰。頭文件放在include目錄并在CMake中通過target_include_directories()將其接口公開這樣測試代碼和主程序都能以統(tǒng)一的方式包含頭文件。注意有些項(xiàng)目喜歡把測試文件放在每個(gè)源文件旁邊如my_math.cpp和my_math_test.cpp在同一目錄。這有其便利性但混合了生產(chǎn)與測試邏輯。對于中大型項(xiàng)目集中式的tests/目錄更利于管理和運(yùn)行例如一鍵運(yùn)行所有測試。本示例采用后者這是一種更普適和可擴(kuò)展的模式。3. 實(shí)操詳解一步步構(gòu)建你的測試體系3.1 根CMakeLists.txt的配置藝術(shù)根目錄的CMakeLists.txt是整個(gè)項(xiàng)目的總控中心。除了定義項(xiàng)目名、版本、語言標(biāo)準(zhǔn)這些基礎(chǔ)信息外它的核心任務(wù)是引入依賴并組織子目錄。cmake_minimum_required(VERSION 3.14) # 確保支持FetchContent project(MyAwesomeProject VERSION 1.0.0 LANGUAGES CXX) # 設(shè)置C標(biāo)準(zhǔn)并令其特性在目標(biāo)間傳遞這是現(xiàn)代CMake的推薦做法 set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) # 關(guān)鍵步驟引入FetchContent模塊 include(FetchContent) # 聲明GoogleTest依賴 FetchContent_Declare( googletest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG release-1.14.0 # 指定一個(gè)穩(wěn)定版本標(biāo)簽 ) # 使依賴可用如果未準(zhǔn)備好則下載并構(gòu)建 FetchContent_MakeAvailable(googletest) # 添加源碼目錄和測試目錄 add_subdirectory(src) # 通常我們只在特定構(gòu)建配置如Debug或顯式要求時(shí)構(gòu)建測試 option(BUILD_TESTS Build the unit tests ON) if(BUILD_TESTS) add_subdirectory(tests) endif()參數(shù)與選擇背后的邏輯CMAKE_CXX_STANDARD_REQUIRED ON這個(gè)設(shè)置非常關(guān)鍵。它告訴CMake如果編譯器不支持你指定的C17標(biāo)準(zhǔn)就直接報(bào)錯(cuò)失敗而不是靜默降級。這能保證你的代碼在所有開發(fā)者的環(huán)境里語法一致。GIT_TAG release-1.14.0這里強(qiáng)烈建議使用具體的發(fā)布版本標(biāo)簽如release-1.14.0而不是main分支。main分支的代碼處于開發(fā)狀態(tài)可能不穩(wěn)定。鎖定一個(gè)已知的穩(wěn)定版本是保證項(xiàng)目長期可復(fù)現(xiàn)構(gòu)建的基礎(chǔ)。option(BUILD_TESTS ... ON)這里定義了一個(gè)CMake選項(xiàng)。在命令行你可以通過-DBUILD_TESTSOFF來跳過測試構(gòu)建加快編譯速度。默認(rèn)設(shè)為ON是為了鼓勵測試但給了使用者關(guān)閉的靈活性。3.2 編寫產(chǎn)品代碼與對應(yīng)的測試用例讓我們假設(shè)一個(gè)極簡的產(chǎn)品代碼一個(gè)數(shù)學(xué)工具庫。include/my_math.h:#pragma once namespace my_math { int add(int a, int b); int divide(int dividend, int divisor); // 可能拋出異常 }src/my_math.cpp:#include my_math.h namespace my_math { int add(int a, int b) { return a b; } int divide(int dividend, int divisor) { if (divisor 0) { throw std::invalid_argument(Divisor cannot be zero!); } return dividend / divisor; } }對應(yīng)的測試文件tests/test_my_math.cpp#include gtest/gtest.h // 由FetchContent引入路徑已自動設(shè)置好 #include my_math.h // 引用項(xiàng)目頭文件 namespace { TEST(MathTest, AddPositiveNumbers) { EXPECT_EQ(my_math::add(1, 2), 3); EXPECT_EQ(my_math::add(10, 20), 30); } TEST(MathTest, AddWithZero) { EXPECT_EQ(my_math::add(0, 5), 5); EXPECT_EQ(my_math::add(5, 0), 5); } TEST(MathTest, DivideNormal) { EXPECT_EQ(my_math::divide(10, 2), 5); EXPECT_EQ(my_math::divide(9, 3), 3); } TEST(MathTest, DivideByZeroThrows) { EXPECT_THROW(my_math::divide(10, 0), std::invalid_argument); // 也可以測試異常的具體信息 // EXPECT_THROW_MESSAGE(...) 需要gtest 1.11 } } // namespace測試用例設(shè)計(jì)心得一個(gè)測試點(diǎn)一個(gè)TESTAddPositiveNumbers和AddWithZero雖然都測試add但關(guān)注點(diǎn)不同。分開寫有利于測試失敗時(shí)快速定位。使用明確的斷言EXPECT_EQ用于驗(yàn)證相等EXPECT_THROW用于驗(yàn)證是否拋出特定異常。gtest提供了豐富的斷言宏ASSERT_*和EXPECT_*ASSERT_*失敗會終止當(dāng)前測試用例EXPECT_*失敗會繼續(xù)執(zhí)行。通常EXPECT_*更常用因?yàn)樗茉谝粋€(gè)測試中收集所有失敗信息。匿名命名空間將測試套件包裹在匿名命名空間里可以避免測試用例名稱與其他翻譯單元沖突是個(gè)好習(xí)慣。3.3 測試目錄的CMakeLists.txt鏈接與定義目標(biāo)這是將一切串聯(lián)起來的地方。tests/CMakeLists.txt需要做三件事創(chuàng)建一個(gè)測試可執(zhí)行文件鏈接必要的庫最后將該可執(zhí)行文件注冊為CTest測試。# 創(chuàng)建一個(gè)測試可執(zhí)行目標(biāo) add_executable(unit_tests test_my_math.cpp # 未來可以繼續(xù)添加其他測試文件如 test_another.cpp ) # 將測試目標(biāo)鏈接到我們的產(chǎn)品庫和gtest庫 # 假設(shè)在 src/CMakeLists.txt 中產(chǎn)品庫目標(biāo)名稱為 my_math_lib target_link_libraries(unit_tests PRIVATE my_math_lib GTest::gtest_main # 鏈接gtest主庫它包含了main函數(shù) ) # 可選但推薦讓測試目標(biāo)也能找到項(xiàng)目頭文件 target_include_directories(unit_tests PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/../include ) # 關(guān)鍵步驟啟用測試并將可執(zhí)行文件添加到CTest enable_testing() add_test(NAME MyMathUnitTests COMMAND unit_tests)深度解析鏈接選項(xiàng)GTest::gtest_main這是一個(gè)由FetchContent引入gtest后CMake自動為我們生成的一個(gè)導(dǎo)入目標(biāo)imported target。鏈接它就等于鏈接了編譯好的gtest庫并且使用了gtest提供的main()函數(shù)。這意味著我們的test_my_math.cpp里不需要自己寫int main()gtest框架會幫我們處理測試的啟動、運(yùn)行和結(jié)果匯總。這是最省心、最標(biāo)準(zhǔn)的方式。PRIVATE關(guān)鍵字這里使用的是現(xiàn)代CMake的target_link_libraries命令PRIVATE表示my_math_lib和GTest::gtest_main的依賴關(guān)系僅用于構(gòu)建unit_tests目標(biāo)本身不會傳遞給其他可能依賴unit_tests的目標(biāo)雖然測試目標(biāo)通常不會被其他目標(biāo)依賴。使用PRIVATE、PUBLIC、INTERFACE來精確控制依賴傳遞是現(xiàn)代CMake的核心思想之一能有效避免依賴泄露和沖突。4. 構(gòu)建、運(yùn)行與結(jié)果解析4.1 標(biāo)準(zhǔn)構(gòu)建流程在項(xiàng)目根目錄執(zhí)行標(biāo)準(zhǔn)的CMake構(gòu)建流程# 1. 生成構(gòu)建系統(tǒng)這里以Unix Makefiles為例在Windows上可以是Visual Studio工程 mkdir build cd build cmake .. -DCMAKE_BUILD_TYPEDebug # 建議在Debug模式下進(jìn)行測試便于調(diào)試 # 2. 編譯項(xiàng)目包括產(chǎn)品代碼和測試代碼 cmake --build . --parallel 4 # 使用4個(gè)并行任務(wù)加速編譯 # 3. 運(yùn)行所有測試 ctest --output-on-failurectest是CMake自帶的測試驅(qū)動程序。--output-on-failure參數(shù)非常有用它會在任何測試失敗時(shí)打印出該測試的詳細(xì)輸出即gtest打印的信息幫助你快速定位問題。如果所有測試通過它只會顯示一個(gè)簡潔的匯總。4.2 直接運(yùn)行測試可執(zhí)行文件獲取更詳細(xì)信息你也可以直接運(yùn)行編譯生成的測試二進(jìn)制文件如./unit_tests這會啟動gtest自帶的runner提供更豐富的交互選項(xiàng)cd build/tests # 進(jìn)入測試可執(zhí)行文件所在目錄 ./unit_tests # 運(yùn)行所有測試 ./unit_tests --gtest_list_tests # 列出所有測試套件和用例 ./unit_tests --gtest_filterMathTest.AddPositiveNumbers # 只運(yùn)行特定測試 ./unit_tests --gtest_repeat1000 --gtest_break_on_failure # 重復(fù)測試1000次失敗時(shí)中斷用于壓力或穩(wěn)定性測試 ./unit_tests --gtest_outputxml:report.xml # 輸出XML格式的測試報(bào)告便于CI系統(tǒng)如Jenkins, GitLab CI解析實(shí)操心得善用過濾器和XML報(bào)告--gtest_filter在開發(fā)調(diào)試階段極其有用。當(dāng)你只修改了某個(gè)函數(shù)不需要跑完所有幾百個(gè)測試用例用過濾器精準(zhǔn)運(yùn)行相關(guān)測試能極大提升開發(fā)效率。XML報(bào)告是持續(xù)集成的標(biāo)配。在項(xiàng)目的CI腳本里最后一步通常是運(yùn)行測試并收集report.xml。CI平臺可以解析這個(gè)文件將測試結(jié)果通過率、失敗用例、耗時(shí)可視化甚至與提交、合并請求關(guān)聯(lián)起來。5. 進(jìn)階技巧與常見問題排查5.1 模擬Mock與測試固件Fixture對于復(fù)雜代碼你經(jīng)常需要測試一個(gè)依賴了其他類或接口的模塊。GoogleTest提供了強(qiáng)大的模擬框架GoogleMock通常與gtest一起發(fā)布。示例測試一個(gè)依賴“網(wǎng)絡(luò)服務(wù)”的類假設(shè)有一個(gè)DataFetcher類依賴一個(gè)NetworkService接口來獲取數(shù)據(jù)。我們不想在單元測試中真的發(fā)起網(wǎng)絡(luò)請求。// 1. 定義模擬類 #include gmock/gmock.h class MockNetworkService : public NetworkService { public: MOCK_METHOD(std::string, fetchData, (const std::string url), (override)); }; // 2. 在測試中使用 TEST(DataFetcherTest, FetchSuccess) { MockNetworkService mockService; DataFetcher fetcher(mockService); // 設(shè)置期望當(dāng)調(diào)用fetchData(example.com)時(shí)返回mock data EXPECT_CALL(mockService, fetchData(example.com)) .WillOnce(::testing::Return(mock data)); EXPECT_EQ(fetcher.process(example.com), processed: mock data); }**測試固件Fixture**用于多個(gè)測試用例共享相同的設(shè)置和清理代碼。比如所有測試都需要一個(gè)初始化好的數(shù)據(jù)庫連接。class DatabaseTest : public ::testing::Test { protected: void SetUp() override { // 在每個(gè)TEST_F運(yùn)行前執(zhí)行類似構(gòu)造函數(shù) db_ std::make_uniqueDatabase(:memory:); // 使用內(nèi)存數(shù)據(jù)庫 db_-initialize(); } void TearDown() override { // 在每個(gè)TEST_F運(yùn)行后執(zhí)行類似析構(gòu)函數(shù) db_-close(); } std::unique_ptrDatabase db_; }; // 使用 TEST_F 而不是 TEST TEST_F(DatabaseTest, InsertRecord) { EXPECT_TRUE(db_-insert(key1, value1)); } TEST_F(DatabaseTest, QueryRecord) { db_-insert(key1, value1); EXPECT_EQ(db_-query(key1), value1); }5.2 常見編譯與鏈接問題排查即使按照示例操作你也可能會遇到一些編譯問題。以下是幾個(gè)高頻問題及解決方案問題1fatal error: gtest/gtest.h: No such file or directory原因編譯器找不到gtest頭文件。這通常是因?yàn)閠arget_link_libraries沒有正確鏈接GTest::gtest或GTest::gtest_main目標(biāo)。現(xiàn)代CMake通過導(dǎo)入目標(biāo)自動管理頭文件包含路徑鏈接了它就等于告訴了編譯器頭文件在哪。解決確保你的tests/CMakeLists.txt中target_link_libraries命令包含了GTest::gtest_main。并且檢查根CMakeLists.txt中FetchContent_MakeAvailable(googletest)是否成功執(zhí)行查看CMake配置輸出。問題2undefined reference totesting::internal::...鏈接錯(cuò)誤原因找到了頭文件但鏈接時(shí)找不到gtest的庫實(shí)現(xiàn)。這同樣是因?yàn)殒溄幽繕?biāo)不正確或順序有問題。解決確認(rèn)鏈接的是GTest::gtest_main如果你沒自定義main函數(shù)或GTest::gtest如果你自定義了main函數(shù)。確保鏈接命令中你的庫在gtest庫之前。在大多數(shù)鏈接器中依賴項(xiàng)的順序很重要。通常的順序是target_link_libraries(your_test_target PRIVATE your_library GTest::gtest_main)。問題3CMake配置時(shí)FetchContent下載失敗或超時(shí)原因網(wǎng)絡(luò)問題或者GitHub訪問不暢。解決設(shè)置網(wǎng)絡(luò)代理注意此處僅討論常規(guī)網(wǎng)絡(luò)配置不涉及任何特殊網(wǎng)絡(luò)工具?？梢栽贑Make命令前設(shè)置環(huán)境變量如export https_proxyhttp://your-proxy:portLinux/macOS或set https_proxyhttp://your-proxy:portWindows CMD。使用國內(nèi)鏡像源。可以修改GIT_REPOSITORY為鏡像地址但需注意鏡像的同步可能滯后。更穩(wěn)妥的方式是在能訪問外網(wǎng)的機(jī)器上預(yù)先下載好gtest的release包放在本地目錄然后修改FetchContent_Declare使用URL和本地文件路徑但這增加了維護(hù)成本。對于團(tuán)隊(duì)內(nèi)部建議維護(hù)一個(gè)穩(wěn)定的內(nèi)網(wǎng)代理或鏡像。問題4測試通過但ctest命令顯示“No tests were found!!!”原因enable_testing()或add_test()命令沒有被執(zhí)行或者執(zhí)行順序有問題。解決確保tests/CMakeLists.txt中的enable_testing()和add_test()命令被調(diào)用。add_test()必須在add_executable()定義目標(biāo)之后。檢查構(gòu)建目錄是否正確。你必須在執(zhí)行cmake ..的build目錄下運(yùn)行ctest而不是在源碼目錄。5.3 集成到IDECLion, VS Code等現(xiàn)代IDE對CMake和GoogleTest的支持都非常好。CLion直接打開項(xiàng)目根目錄包含頂層CMakeLists.txt的目錄CLion會自動識別CMake項(xiàng)目并配置。你可以在“Run/Debug Configurations”中輕松添加“Google Test”配置并選擇運(yùn)行所有測試或特定測試。側(cè)邊欄會有專門的“測試”工具窗口顯示所有測試用例樹狀圖點(diǎn)擊即可運(yùn)行。Visual Studio使用“Open Folder”功能打開項(xiàng)目根目錄VS的CMake集成會掃描項(xiàng)目。你可以在“Test Explorer”窗口中看到所有發(fā)現(xiàn)的測試用例并圖形化地運(yùn)行和調(diào)試。VS Code需要安裝CMake Tools和C擴(kuò)展。配置好后狀態(tài)欄會有CMake的構(gòu)建和調(diào)試選項(xiàng)。測試運(yùn)行通?？梢酝ㄟ^配置launch.json來調(diào)用編譯好的測試可執(zhí)行文件或者使用CMake Tools提供的測試運(yùn)行器。一個(gè)VS Code的實(shí)用技巧在.vscode/settings.json中配置讓CMake在配置時(shí)自動傳遞-DBUILD_TESTSON參數(shù)這樣每次生成構(gòu)建系統(tǒng)時(shí)都會包含測試目標(biāo)。{ cmake.configureArgs: [ -DBUILD_TESTSON ] }6. 從示例到生產(chǎn)你需要考慮的更多事情這個(gè)示例項(xiàng)目給了你一個(gè)堅(jiān)實(shí)的起點(diǎn)但在一個(gè)真實(shí)的、持續(xù)迭代的生產(chǎn)項(xiàng)目中你還需要考慮以下幾點(diǎn)1. 測試覆蓋率Coverage知道測試通過了很重要但知道有多少代碼被測試到了同樣重要?？梢允褂孟駁cov/lcovGCC/Clang或OpenCppCoverageMSVC這樣的工具來生成覆蓋率報(bào)告。集成到CMake中通常需要開啟特定的編譯標(biāo)志如-fprofile-arcs -ftest-coverage并在構(gòu)建后運(yùn)行腳本生成HTML報(bào)告。許多CI系統(tǒng)如GitLab CI也原生支持覆蓋率收集和可視化。2. 基準(zhǔn)測試Benchmark單元測試驗(yàn)證正確性基準(zhǔn)測試驗(yàn)證性能。Google有一個(gè)相關(guān)的開源項(xiàng)目叫Google Benchmark它可以和GoogleTest類似地通過FetchContent集成用于測試關(guān)鍵函數(shù)或算法的性能防止性能回歸。3. 持續(xù)集成CI將這套CMake構(gòu)建和測試流程集成到CI/CD管道中是必經(jīng)之路。無論是GitHub Actions、GitLab CI還是Jenkins核心步驟都是一樣的在干凈的容器或環(huán)境中檢出代碼 - 安裝CMake/編譯器 - 配置項(xiàng)目cmake -B build -DBUILD_TESTSON - 編譯cmake --build build - 運(yùn)行測試cd build ctest --output-on-failure。CI能確保每次提交都不會破壞現(xiàn)有功能。4. 測試代碼的質(zhì)量測試代碼也是代碼也需要保持清晰、可維護(hù)。遵循DRYDon‘t Repeat Yourself原則使用固件或輔助函數(shù)來消除重復(fù)設(shè)置。給測試用例起一個(gè)清晰、描述性的名字。避免測試邏輯過于復(fù)雜一個(gè)測試最好只驗(yàn)證一件事。我個(gè)人在多個(gè)項(xiàng)目中實(shí)踐這套方法后最大的體會是投資于構(gòu)建系統(tǒng)和測試基礎(chǔ)設(shè)施的時(shí)間會在項(xiàng)目生命周期中十倍、百倍地回報(bào)給你。它帶來的確定性、協(xié)作順暢度和重構(gòu)勇氣是任何臨時(shí)方案都無法比擬的。這個(gè)GoogleTest與CMake的實(shí)踐示例就是為你打下這個(gè)堅(jiān)實(shí)基礎(chǔ)的第一塊、也是最重要的一塊磚。