C ++ Google Test在哪里放置測試裝置構造函數定義

Question

我最近將Google Test用於我的C ++代碼。 當我閱讀如何設置測試夾具進行測試時，我有些困惑。 編寫main（）函數會話顯示了有關測試治具類外觀的示例。 但是，當涉及到構造函數定義時，是否應該將其放在測試夾具類中？ 例如，類似於google測試文檔給出的以下代碼段：

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)的定義，似乎對於與同一測試夾具關聯的每個測試，該宏都會創建測試夾具類的新子類。

鑒於上述事實，

1. 如果構造函數的工作很繁重，是否意味着測試夾具的構造函數的隱式inline將允許編譯器在任何地方擴展構造函數的大型代碼？ （或者在同一個翻譯單元中沒關系嗎？）

2. 在這種情況下，在測試夾具類之外定義構造函數是否更有意義？ 但這會降低測試代碼的可讀性，我真的不知道該怎么辦。

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

Answer 1

關於問題1，這完全取決於編譯器-可以自由決定是否以及如何內聯函數。 即使您將函數顯式聲明為inline ，就編譯器而言，它仍然只是一個建議，如果它決定生成的機器代碼過於腫或效率低下，則可以隨意忽略該建議。

C ++常見問題解答包含有關該主題的更多詳細信息：

有幾種方法可以指定函數為內聯，其中一些涉及inline關鍵字，而其他則不涉及。 無論您如何將函數指定為內聯函數，都要求編譯器忽略該請求：編譯器可能會內聯擴展您調用被指定為內聯函數的位置的部分，全部或全部。 （不要灰心，因為這似乎是無望的模糊。上述的靈活性實際上是一個巨大的優勢：它使編譯器對大型函數與小型函數的處理不同，此外，它使編譯器生成易於調試的代碼（如果選擇）正確的編譯器選項。）

關於問題2，我建議您隨便閱讀最容易理解的內容。 當我使用Google Tests時，我個人將所有“共享”代碼放在測試夾具定義中，然后緊接着在該夾具中運行的所有單元測試的TEST_F聲明。

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

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

// ...more tests...

不過，這只是一個建議。 選擇一個適合您的標准並持續使用它。