2. 程式人生 > >Google C++單元測試框架---Gtest框架簡介（譯文）

Google C++單元測試框架---Gtest框架簡介（譯文）

阿新 • • 發佈：2019-01-25

一、設定一個新的測試專案

  在用google test寫測試專案之前，需要先編譯gtest到library庫並將測試與其連結。我們為一些流行的構建系統提供了構建檔案: msvc/ for Visual Studio, xcode/ for Mac Xcode, make/ for GNU make, codegear/ for Borland C++ Builder.

如果你的構建系統不在這個名單上，在googletest根目錄有autotools的指令碼（不推薦使用）和CMakeLists.txtCMake（推薦）。你可以看看make / Makefile來了解如何編譯Google Test（基本上你想在標頭檔案中使用GTEST_ROOT和GTEST_ROOT / include來編譯src / gtest-all.cc路徑，其中GTEST_ROOT是Google測試根目錄）。

  一旦你能夠編譯google test庫，您應該為您的測試程式建立一個專案或構建目標。Make sure you have GTEST_ROOT/include in the header search path so that the compiler can find "gtest/gtest.h" when compiling your test.把google test庫加到你的測試專案中（比如：在VS中在gtest.vcproj上新增依賴）。

二、基本概念

當使用谷歌測試，您首先要寫斷言，斷言是檢查條件是否為真的語句。一個斷言的結果可以是成功，非致命性失敗，或致命的失敗。如果一個致命失敗出現，它會終止當前的函式；否則程式繼續正常執行。

測試使用斷言驗證程式碼的行為。如果一個測試崩潰或者有一個失敗的斷言，那麼失敗；否則成功。

一個測試用例包含一個或多個測試。 您應該將測試分組為反映測試程式碼結構的測試用例。當測試用例中的多個測試需要共享公共的物件和子程式時，你可以把它們放進一個test fixture class（測試夾具類）。

一個測試程式可以包含多個測試用例。

現在我們將解釋如何編寫測試程式，從單個斷言級別開始，並構建測試和測試用例。

三、斷言

    Google Test斷言是類似於函式呼叫的巨集。您可以通過對其行為進行斷言來測試類或函式。當斷言失敗時，Google Test會列印斷言的原始檔和行號位置以及失敗訊息。您還可以提供自定義失敗訊息，該訊息將附加到Google測試的資訊中。

斷言是成對的，測試同一件事，但對當前函式有不同的影響。 ASSERT_ *版本在失敗時會生成致命錯誤，並中止當前函式。 EXPECT_ *版本生成非致命性故障，不會中止當前函式。通常優先使用EXPECT_ *，因為它們允許在測試中報告多個故障。但是，如果失敗時函式繼續執行沒有意義，則應使用ASSERT_ *。

因為失敗的ASSERT_ *立即從當前函式返回，可能跳過其後的清理程式碼，它可能導致資源洩漏。根據洩漏的性質，它可能值得修復也可能不值得修復--所以把這個記在心裡，如果你有一個堆檢測錯誤需要注意是什麼導致的。

要提供自定義失敗訊息，只需使用<<運算子或一系列此類運算子將其流式傳輸到巨集中即可。一個例子：

1

2

3

4

5

ASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length";

for (int i = 0; i < x.size(); ++i) {

EXPECT_EQ(x[i], y[i]) << "Vectors x and y differ at index " << i;

}

　　示例：

1

EXPECT_EQ(0, strcmp(s.c_string(), kHelloString2)) << "s.c_string:" << s.c_string() << " kHelloString:" << +kHelloString ;  

　

   任何可以流式傳輸到ostream的東西都可以流式傳輸到斷言巨集，特別是C字串和字串物件。 如果一個寬字串（Windows上的wchar_t *，TCHAR *在UNICODE模式下，或者std :: wstring）被流化到一個斷言，當列印時它將被轉換為UTF-8。

四、基本斷言

這些斷言做基本的真/假條件測試。

Fatal assertion Nonfatal assertion Verifies
ASSERT_TRUE(condition); EXPECT_TRUE(condition); condition is true
ASSERT_FALSE(condition); EXPECT_FALSE(condition); condition is false

記住，當它們失敗時，ASSERT_ *產生致命失敗並從當前函式返回，而EXPECT_ *產生非致命失敗，允許函式繼續執行。 在任一情況下，斷言失敗意味著其包含的測試失敗。

五、二進位制比較

本節介紹比較兩個值的斷言。

Fatal assertion Nonfatal assertion Verifies
ASSERT_EQ(val1,val2); EXPECT_EQ(val1,val2); val1 == val2
ASSERT_NE(val1,val2); EXPECT_NE(val1,val2); val1 != val2
ASSERT_LT(val1,val2); EXPECT_LT(val1,val2); val1 < val2
ASSERT_LE(val1,val2); EXPECT_LE(val1,val2); val1 <= val2
ASSERT_GT(val1,val2); EXPECT_GT(val1,val2); val1 > val2
ASSERT_GE(val1,val2); EXPECT_GE(val1,val2); val1 >= val2

在發生故障時，Google測試同時列印val1和val2。

值引數通過斷言的比較運算子必須可以比較，否則會出現編譯錯誤。我們曾經要求引數支援<<運算子，用於流傳輸到ostream，但從v1.6.0它不再需要（如果支援<<，則會在斷言失敗時呼叫它來列印引數;否則Google Test將嘗試以最佳方式列印它們。有關更多詳細資訊和如何自定義引數的列印，請參閱此Google Mock recipe.。

這些斷言可以使用使用者定義的型別，但是隻有當你定義了相應的比較運算子（例如==，<，etc）。如果定義了相應的操作符，則更喜歡使用ASSERT _ *（）巨集，因為它們不僅會列印比較結果，而且還會打印出兩個運算元。

引數總是隻計算一次。因此，引數有副作用沒關係。然而，與任何普通的C / C ++函式一樣，引數的求值順序是未定義的（即編譯器可以自由選擇任何順序），你的程式碼不應該依賴於任何特定的引數求值順序。

ASSERT_EQ（）指標的指標相等。如果在兩個C字串上使用，它會測試它們是否在同一個記憶體位置，而不是它們具有相同的值。因此，如果你想比較C字串（例如const char *）的值，使用ASSERT_STREQ（），稍後將會描述。特別地，要斷言C字串為NULL，請使用ASSERT_STREQ（NULL，c_string）。但是，要比較兩個字串物件，應該使用ASSERT_EQ。

本節中的巨集適用於窄和寬字串物件（string和wstring）。

歷史記錄：2016年2月之前* _EQ有一個約定，稱為ASSERT_EQ（expected,actual），所以很多現有的程式碼使用這個順序。 現在* _EQ以相同的方式處理這兩個引數。

六、字串比較

該組中的斷言比較兩個C字串的值。 如果要比較兩個字串物件，請改用EXPECT_EQ，EXPECT_NE和etc。

Fatal assertion Nonfatal assertion Verifies
ASSERT_STREQ(str1,str2); EXPECT_STREQ(str1,_str_2); the two C strings have the same content
ASSERT_STRNE(str1,str2); EXPECT_STRNE(str1,str2); the two C strings have different content
ASSERT_STRCASEEQ(str1,str2); EXPECT_STRCASEEQ(str1,str2); the two C strings have the same content, ignoring case(忽略大小寫)
ASSERT_STRCASENE(str1,str2); EXPECT_STRCASENE(str1,str2); the two C strings have different content, ignoring case

注意，斷言名中的“CASE”表示忽略大小寫。

* STREQ *和* STRNE *也接受寬C字串（wchar_t *）。 如果兩個寬字串的比較失敗，它們的值將列印為UTF-8窄字串。

NULL指標和空字串被認為是不同的。

可用性：Linux，Windows，Mac。

另請參閱：有關更多字串比較技巧（例如，子字串，字首，字尾和正則表示式匹配），請參見高階Google測試指南(Advanced Google Test Guide.)。

七、簡單測試

建立測試：

  1.使用TEST（）巨集來定義和命名測試函式，這些是不返回值的普通C++函式。
  2.在此函式中，連同要包括的任何有效的C++語句，使用各種Google Test斷言來檢查值。
  3.測試的結果由斷言確定; 如果測試中的任何斷言失敗（致命或非致命），或者如果測試崩潰，則        整個測試失敗。 否則，它成功。

1

2

3

TEST(test_case_name, test_name) {

... test body ...

}

TEST（）引數從一般到特定。 第一個引數是測試用例的名稱，第二個引數是測試用例中的測試名稱。 這兩個名稱必須是有效的C ++識別符號，並且它們不應包含下劃線（_）。 測試的全名由其包含的測試用例及其個人名稱組成。來自不同測試用例的測試可以具有相同的個人名稱。

例如，讓我們使用一個簡單的整數函式：

1

int Factorial(int n); // Returns the factorial of n；n！

　　此函式的測試用例可能如下所示：

1

2

3

4

5

6

7

8

9

10

11

12

// Tests factorial of 0.

TEST(FactorialTest, HandlesZeroInput) {

EXPECT_EQ(1, Factorial(0));

}

// Tests factorial of positive numbers.

TEST(FactorialTest, HandlesPositiveInput) {

EXPECT_EQ(1, Factorial(1));

EXPECT_EQ(2, Factorial(2));

EXPECT_EQ(6, Factorial(3));

EXPECT_EQ(40320, Factorial(8));

}　

Google Test通過測試用例對測試結果進行分組，因此邏輯相關的測試應該在同一測試用例中; 換句話說，它們的TEST（）的第一個引數應該是相同的。 在上面的例子中，我們有兩個測試，HandlesZeroInput和HandlesPositiveInput，屬於同一個測試用例FactorialTest。

八、測試夾具(Test Fixtures)：對多個測試使用相同的資料配置

如果你發現自己寫了兩個或更多的測試來操作類似的資料，你可以使用測試夾具。它允許您為幾個不同的測試重複使用相同的物件配置。

要建立夾具，只需：

  1.從:: testing :: Test派生一個類。 使用protected：或public：開始它的主體，因為我們想從子類     訪問fixture成員。
  2.在類中，宣告你打算使用的任何物件。
  3.如果需要，可以編寫預設建構函式或SetUp（）函式來為每個測試準備物件。 一個常見的錯誤是     拼寫SetUp（）為Setup（）與一個小u -- 不要讓這種情況發生在你身上。
  4.如果需要，寫一個解構函式或TearDown（）函式來釋放你在SetUp（）中分配的任何資源。 要     學習什麼時候應該使用建構函式/解構函式，當你應該使用SetUp（）/ TearDown（）時，請閱讀這個 FAQ entry.。
  5.如果需要，定義要分享的測試的子程式。

當使用夾具時，使用TEST_F（）而不是TEST（），因為它允許您訪問測試夾具中的物件和子程式：

1

2

3

TEST_F(test_case_name, test_name) {

... test body ...

}

和TEST（）一樣，第一個引數是測試用例名，

但是對於TEST_F（）第一個引數必須是測試夾具類的名稱。 你可能猜到了：_F是夾具。

不幸的是，C ++巨集系統不允許我們建立一個可以處理兩種型別的測試的巨集。 使用錯誤的巨集會導致編譯器錯誤。

另外，在TEST_F（）中使用它之前，你必須首先定義一個測試夾具類，否則將得到編譯器錯誤“virtual outside class declaration”。

對於使用TEST_F（）定義的每個測試，Google Test將：

  1.在執行時建立一個新的測試夾具
  2.立即通過SetUp（）初始化，
  3.執行測試
  4.通過呼叫TearDown（）清除
  5.刪除測試夾具。 請注意，同一測試用例中的不同測試具有不同的測試夾具物件，Google測試始     終會刪除測試夾具，然後再建立下一個測試夾具。 Google測試不會為多個測試重複使用相同的       測試夾具。一個測試對夾具的任何更改不會影響其他測試。

例如，讓我們為名為Queue的FIFO佇列類編寫測試，它有以下介面：

1

2

3

4

5

6

7

8

9

template <typename E> // E is the element type.

class Queue {

public:

Queue();

void Enqueue(const E& element);

E* Dequeue(); // Returns NULL if the queue is empty.

size_t size() const;

...

};

　　首先定義一個夾具類。按照慣例，你應該給它名稱FooTest，其中Foo是被測試的類。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

class QueueTest : public ::testing::Test {

protected:

virtual void SetUp() {

q1_.Enqueue(1);

q2_.Enqueue(2);

q2_.Enqueue(3);

}

// virtual void TearDown() {}

Queue<int> q0_;

Queue<int> q1_;

Queue<int> q2_;

};

在這種情況下，不需要TearDown（），因為我們不必在每次測試後清理，除了解構函式已經做了什麼。

現在我們將使用TEST_F（）和這個夾具編寫測試。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

TEST_F(QueueTest, IsEmptyInitially) {

EXPECT_EQ(0, q0_.size());

}

TEST_F(QueueTest, DequeueWorks) {

int* n = q0_.Dequeue();

EXPECT_EQ(NULL, n);

n = q1_.Dequeue();

ASSERT_TRUE(n != NULL);

EXPECT_EQ(1, *n);

EXPECT_EQ(0, q1_.size());

delete n;

n = q2_.Dequeue();

ASSERT_TRUE(n != NULL);

EXPECT_EQ(2, *n);

EXPECT_EQ(1, q2_.size());

delete n;

}

上面使用ASSERT_ *和EXPECT_ *斷言。 經驗法則( The rule of thumb )是當你希望測試在斷言失敗後繼續顯示更多錯誤時使用EXPECT_ *，或是在失敗後繼續使用ASSERT_ *沒有意義。 例如，Dequeue測試中的第二個斷言是ASSERT_TRUE（n！= NULL），因為我們需要稍後解引用指標n，這將導致n為NULL時的segfault。

當這些測試執行時，會發生以下情況：

  1.Google Test構造了一個QueueTest物件（我們稱之為t1）。 
  2.t1.SetUp（）初始化t1。 
  3.第一個測試（IsEmptyInitially）在t1上執行。 
  4.t1.TearDown（）在測試完成後清理。 
  5.t1被析構。 
  6.以上步驟在另一個QueueTest物件上重複，這次執行DequeueWorks測試。

九、呼叫測試

TEST（）和TEST_F（）用Google Test隱式註冊他們的測試。 因此，與許多其他C ++測試框架不同，您不必重新列出所有定義的測試以執行它們。

定義測試後，可以使用RUN_ALL_TESTS（）執行它們，如果所有測試成功則返回0，否則返回1。 請注意，RUN_ALL_TESTS（）執行連結單元中的所有測試 - 它們可以來自不同的測試用例，甚至是不同的原始檔。

呼叫時，RUN_ALL_TESTS（）巨集：

  1. 儲存所有Google測試標記的狀態。
  2. 為第一個測試建立測試夾具物件。
  3. 通過SetUp（）初始化它。
  4. 在fixture物件上執行測試。
  5. 通過TearDown（）清除夾具。
  6. 刪除夾具。
  7. 恢復所有Google測試標誌的狀態。
  8. 重複上述步驟進行下一個測試，直到所有測試執行結束。

此外，如果測試夾具的建構函式在步驟2中產生致命故障，則步驟3-5沒有意義，因此它們被跳過。 類似地，如果步驟3產生致命故障，則將跳過步驟4。

重要：您不能忽略RUN_ALL_TESTS（）的返回值，否則gcc將給您一個編譯器錯誤。 此設計的基本原理是自動測試服務基於其退出程式碼而不是其stdout / stderr輸出來確定測試是否已通過; 因此您的main（）函式必須返回RUN_ALL_TESTS（）的值。

此外，您應該只調用一次RUN_ALL_TESTS（）。 多次呼叫它會與一些高階Google測試功能（例如執行緒安全死亡測試）衝突，因此不受支援。

 十、寫Main函式

你可以從這個樣板開始：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

#include "this/package/foo.h"

#include "gtest/gtest.h"

namespace {

// The fixture for testing class Foo.

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.

}

// If the constructor and destructor are not enough for setting up

// and cleaning up each test, you can define the following methods:

virtual void SetUp() {

// Code here will be called immediately after the constructor (right

// before each test).

}

virtual void TearDown() {

// Code here will be called immediately after each test (right

// before the destructor).

}

// Objects declared here can be used by all tests in the test case for Foo.

};

// Tests that the Foo::Bar() method does Abc.

TEST_F(FooTest, MethodBarDoesAbc) {

const string input_filepath = "this/package/testdata/myinputfile.dat";

const string output_filepath = "this/package/testdata/myoutputfile.dat";

Foo f;

EXPECT_EQ(0, f.Bar(input_filepath, output_filepath));

}

// Tests that Foo does Xyz.

TEST_F(FooTest, DoesXyz) {

// Exercises the Xyz feature of Foo.

}

}  // namespace

int main(int argc, char **argv) {

::testing::InitGoogleTest(&argc, argv);

return RUN_ALL_TESTS();

}

:: testing :: InitGoogleTest（）函式解析Google測試標誌的命令列，並刪除所有已識別的標誌。 這允許使用者通過各種標誌控制測試程式的行為，我們將在AdvancedGuide中介紹。 在呼叫RUN_ALL_TESTS（）之前必須呼叫此函式，否則標誌將無法正確初始化。

在Windows上，InitGoogleTest（）也適用於寬字串，因此它也可以在以UNICODE模式編譯的程式中使用。

但也許你認為編寫所有這些main（）函式是太多的工作？ 我們完全同意你的看法，這就是為什麼Google Test提供了main（）的基本實現。 如果它適合你的需要，然後只是連結你的測試與gtest_main庫。

十 一、Visual C ++使用者的重要說明

如果你把你的測試放入一個庫，你的main（）函式在不同的庫或在你的 .exe檔案中，這些測試將不會執行。 原因是Visual C ++中的一個錯誤。 當您定義測試時，Google測試會建立一些靜態物件來註冊它們。 這些物件沒有從其他地方引用，但它們的建構函式仍然應該執行。 當Visual C ++連結器發現庫中沒有從其他地方引用時，它會丟擲該庫。 您必須通過主程式中的測試來引用您的庫，以防止連結器丟棄它。 這裡是如何做到的。 在你的庫程式碼中宣告一個函式：

。。。。。省略啦，如果用VC再來看。

十二、從這裡到哪裡去

恭喜！ 您已學習了Google測試基礎知識。 您可以開始編寫和執行Google Test測試，閱讀一些示例，或繼續閱讀AdvancedGuide，其中介紹了更多有用的Google測試功能。

十三、已知的限制

Google測試旨線上程安全。 在pthreads庫可用的系統上，實現是執行緒安全的。 目前，在其他系統（例如Windows）上同時使用兩個執行緒的Google Test斷言是不安全的。 在大多數測試中，這不是一個問題，因為通常斷言是在主執行緒中完成的。 如果你想幫助，你可以志願為您的平臺在gtest-port.h中實現必要的同步原語。

相關推薦

Google C++單元測試框架---Gtest框架簡介（譯文）

一、設定一個新的測試專案   在用google test寫測試專案之前，需要先編譯gtest到library庫並將測試與其連結。我們為一些流行的構建系統提供了構建檔案: msvc/ for Visual Studio, xcode/ for Mac Xcode, make/

Google C++單元測試框架---Gtest框架簡介（譯文）[轉載]

一、設定一個新的測試專案  在用google test寫測試專案之前，需要先編譯gtest到library庫並將測試與其連結。我們為一些流行的構建系統提供了構建檔案: msvc/ for Visual Studio, xcode/ for Mac Xcode, make/ f

Google C++ 單元測試 GTest

from : http://www.cnblogs.com/jycboy/p/6057677.html 一、設定一個新的測試專案   在用google test寫測試專案之前，需要先編譯gtest到library庫並將測試與其連結。我們為一些流行的構建系統提供了構建檔案: msvc/ for Visual

微服務框架-Spring Cloud簡介（一）

-o 包括 解決 簡介 方法 應用 原本 conf 產品 Spring Cloud是一個微服務框架，相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系統解決方案。 Spring Cloud對微服務基礎框架Netflix的多個開源組件進行了封裝，同時

Android單元測試的利器：Juint（三）：Juint的詳細用法（上）

前言 這幾天正在成都出差，欣賞著成都的妹紙。 當我開始寫這篇的時候是上週五，沒想到這麼快就星期二了，東西越寫越多，為了保持文章儘量短小精悍，Juint的詳細用法就分成多篇來寫把，具體能寫幾篇我也不清楚… 正文 Assertions（斷言） 斷言

接口測試之接口簡介（一）

ner 服務 data 獲取 求和 data- http協議 tro 傳遞 1、接口定義 　　接口：一般分兩種類型，一種是程序內部的接口，一種系統對外的接口。 　　程序內部接口：即程序內部方法與方法之間，模塊與模塊之間的交互。例如論壇系統中，存在登錄和發帖模塊，而發帖必

基於測試的專案進度管理（譯文）

　　一、介紹 　　這是一篇英文的文獻，昨天把他翻譯出來了。覺得還是比較有用，所以決定在這裡把它貼出來。原文在： 　　http://www.stickyminds.com/sitewide.asp?ObjectId=10094&Function=DETAILB

Google開源C++ 單元測試框架Google Test系列(gtest)之初始gtest

    下載           最新原始碼地址：https://github.com/google/googletest           V1.3和V1.

玩轉Google開源C++單元測試框架Google Test系列(gtest)(總)

前段時間學習和了解了下Google的開源C++單元測試框架Google Test，簡稱gtest，非常的不錯。 我們原來使用的是自己實現的一套單元測試框架，在使用過程中，發現越來越多使用不便之處，而這樣不便之處，gtest恰恰很好的解決了。 其實gtest本身的實現並不複雜

Google開源C++單元測試框架Google Test系列(gtest)之斷言

     gtest中，斷言的巨集可以理解為分為兩類，一類是ASSERT系列，一類是EXPECT系列。一個直觀的解釋就是： ASSERT_* 系列的斷言，當檢查點失敗時，退出當前函式（注意：並非退出當前案例）。   EXPECT_* 系列的斷言，當檢查點失敗時，繼續往下

Google開源C++單元測試框架Google Test系列(gtest)之引數化

      在設計測試案例時，經常需要考慮給被測函式傳入不同的值的情況。我們之前的做法通常是寫一個通用方法，然後編寫在測試案例呼叫它。即使使用了通用方法，這樣的工作也是有很多重複性的，程式設計師都懶，都希望能夠少寫程式碼，多複用程式碼。      Google的程式設計師也

Google開源C++單元測試框架Google Test系列(gtest)之- 事件機制

gtest提供了多種事件機制，非常方便我們在案例之前或之後做一些操作。總結一下gtest的事件一共有3種： 全域性的，所有案例執行前後。 TestSuite級別的，在某一批案例中第一個案例前，最後一個案例執行後  TestCase級別的，每個TestCase前後。 全域

Gtest：死亡測試 玩轉Google開源C++單元測試框架Google Test系列(gtest)之五 - 死亡測試

轉自：玩轉Google開源C++單元測試框架Google Test系列(gtest)之五 - 死亡測試 一、前言 “死亡測試”名字比較恐怖，這裡的“死亡”指的的是程式的崩潰。通常在測試過程中，我們需要考慮各種各樣的輸入，有的輸入可能直接導致程式崩潰，這時我們就需要檢查程式是否按照預期的方式掛掉，這也就是所

Gtest：引數化 玩轉Google開源C++單元測試框架Google Test系列(gtest)之四 - 引數化

轉自：玩轉Google開源C++單元測試框架Google Test系列(gtest)之四 - 引數化 一、前言 在設計測試案例時，經常需要考慮給被測函式傳入不同的值的情況。我們之前的做法通常是寫一個通用方法，然後編寫在測試案例呼叫它。即使使用了通用方法，這樣的工作也是有很多重複性的，程式設計師都懶，都希望

玩轉Google開源C++單元測試框架Google Test系列(gtest)之一

一、前言本篇將介紹一些gtest的基本使用，包括下載，安裝，編譯，建立我們第一個測試Demo工程，以及編寫一個最簡單的測試案例。 二、下載如果不記得網址， 直接在google裡搜gtest，第一個就是。目前gtest的最新版本為1.3.0，從下列地址可以下載到該最新版本：三、

玩轉Google開源C++單元測試框架Google Test系列(gtest)之六

一、前言使用gtest編寫的測試案例通常本身就是一個可執行檔案，因此執行起來非常方便。同時，gtest也為我們提供了一系列的執行引數（環境變數、命令列引數或程式碼裡指定），使得我們可以對案例的執行進行一些有效的控制。二、基本介紹前面提到，對於執行引數，gtest提供了三種設定

玩轉Google開源C++單元測試框架Google Test系列(gtest)之五

一、前言 “死亡測試”名字比較恐怖，這裡的“死亡”指的的是程式的崩潰。通常在測試過程中，我們需要考慮各種各樣的輸入，有的輸入可能直接導致程式崩潰，這時我們就需要檢查程式是否按照預期的方式掛掉，這也就是所謂的“死亡測試”。gtest的死亡測試能做到在一個安全的環境下執行崩潰的

玩轉Google開源C++單元測試框架Google Test系列(gtest)之四

一、前言在設計測試案例時，經常需要考慮給被測函式傳入不同的值的情況。我們之前的做法通常是寫一個通用方法，然後編寫在測試案例呼叫它。即使使用了通用方法，這樣的工作也是有很多重複性的，程式設計師都懶，都希望能夠少寫程式碼，多複用程式碼。Google的程式設計師也一樣，他們考慮到了

C單元測試框架——CMockery簡介與示例

簡介 是google釋出的用於C單元測試的一個輕量級的框架。 主要特點： 免費且開源，google提供技術支援；輕量級的框架，使測試更加快速簡單；避免使用複雜的編譯器特性，對老版本的編譯器來講，相容性好;並不強制要求待測程式碼必須依賴C99標準，這一特性對許多嵌入式

CPPUTest 單元測試框架(針對 C 單元測試的使用說明)

CPPUTest 雖然名稱上看起來是 C++ 的單元測試框架, 其實它也是支援測試 C 程式碼的. 本文主要介紹用CPPUTest來測試 C 程式碼. (C++沒用過, 平時主要用的是C) C++相關的內容都省略了. 本文基於 debian v7.6 x86_64. 1. CPPUTest 安裝 現在各