C++ Google Test測試夾具的構造器定義

我最近使用Google Test for C++代碼。當我閱讀如何設置測試夾具時，我感到有點困惑。 Writing the main() Function會議展示了一個關於測試夾具類看起來像什麼的例子。但是，當涉及到構造函數定義時，我們應該把它放在測試夾具類中嗎？例如，就像谷歌測試文檔給出下面的代碼片段：C++ Google Test測試夾具的構造器定義

class FooTest : public ::testing::Test { 
protected: 
    // You can remove any or all of the following functions if its body 
    // is empty. 

    FooTest() { 
    // You can do set-up work for each test here. 
    } 

    virtual ~FooTest() { 
    // You can do clean-up work that doesn't throw exceptions here. 
    } 
}

我也看了在宏觀TEST_F(test_fixture_name, test_name)的定義，它似乎是與同一測試夾具相關聯的每個測試，宏將創建一個測試夾具類的新子類。

鑑於上述事實，

如果構造的工作是沉重的，這是否意味着測試夾具的構造將讓編譯器擴展構造的大塊的代碼隨處可見的隱含inline？（或者在同一個翻譯單元中這沒有關係？）
在這種情況下，在測試夾具類之外定義構造函數是否更有意義？但是這樣會使測試代碼不易讀，我不知道該怎麼辦。

有沒有人可以給我一些建議呢？謝謝！

來源

2017-01-10 Dreamer

關於問題1，完全取決於編譯器 - 它具有廣泛的自由度來決定是否以及如何內聯函數。即使您明確聲明函數爲inline，但就編譯器而言，它仍然只是一個建議，如果它決定生成的機器代碼太臃腫或效率低下，則可以自由忽略該建議。

的C++ FAQ對話題的更多細節：

有幾種方法來指定一個功能是內聯，其中一些涉及inline關鍵字，有的則沒有。無論您如何將函數指定爲內聯函數，它都是允許編譯器忽略的請求：編譯器可能會內聯展開一些或全部或者沒有調用指定爲內聯的函數的地方。（如果看起來毫無希望地模糊，不要灰心，上面的靈活性實際上是一個巨大的優勢：它可以讓編譯器把大的函數與小函數區分開來，再加上它讓編譯器生成代碼，如果你選擇了易於調試的代碼正確的編譯器選項。）

在問題2中，我建議您只需要找出最具可讀性的內容。當我使用Google測試時，我親自將所有「共享」代碼放入測試夾具定義中，然後立即對該夾具中運行的所有單元測試執行TEST_F聲明。

class MyTestCase : public ::testing::Test 
{ 
    virtual void SetUp() override 
    { 
     // ... 
    } 
} 

TEST_F(MyTestCase, UnitTestNumber1) 
{ 
    // testing stuff here 
} 

// ...more tests...

雖然這只是一個建議。選擇適合您的標準並持續使用。

來源

2017-01-10 01:36:32

C++ Google Test測試夾具的構造器定義

回答

相關問題