一、簡介  

     之所以叫溫故而知新，是因為將這兩個工具結合起來作為單元測試工具的想法在上一個專案中應用了，好像還沒有人將這兩種工具結合使用，或者沒有寫成部落格供大家參考，現在重新溫習下將想法寫下來。

    gtest單元測試工具接觸過的人都很熟悉了，它是一款google提供的強大的測試框架，測試案例的編寫也比較簡單，gtest案例的編寫可以參考系列博文:http://www.cnblogs.com/coderzh/archive/2009/03/31/1426758.html。

    lcov程式碼覆蓋率統計工具，是gcov的延伸版本，提供程式實際執行的資訊（統計某行程式碼被執行的次數），其基於HTML的輸出通過瀏覽器以清晰的圖表形式呈現覆蓋率統計結果。locv相關詳細介紹可以參考博文：https://my.oschina.net/alphajay/blog/33725

二、gtest環境的搭建步驟：

（1）下載原始碼包搭建：

參考博文：http://www.linuxidc.com/Linux/2015-05/116894.htm。

我是按照這篇部落格的步驟下載原始碼將多餘的目錄刪除最後在gtest_tool目錄下只剩下兩個核心程式碼目錄：

（2）直接輸入命令安裝： sudo apt-get install libgtest-dev

三、lcov工具的安裝：

（1）下載原始碼包：http://ltp.sourceforge.net/coverage/lcov.php

（2）解壓：tar xvzf lcov-1.11.tar.gz

（3）cd lcov-1.11

（4）如果是交叉編譯移植到實機上需要執行這步：

修改檔案：lcov-1.11/bin/genifo
                    vim lcov-1.11/bin/genifo
然後將第65行的：our $gcov_tool = "gcov" 改為自己的交叉編譯器的gcov

比如我的交叉編譯工具是/usr/local/arm/4.3.2/bin/arm-linux-gcc
那麼就改為：our $gcov_tool = "/usr/local/arm/4.3.2/bin/arm-linux-gcov"

可以使用：find / -name *gcov來查詢下自己的交叉編譯工具在什麼目錄下

（5）sudo make install

注：除了下載原始碼包還可以執行下面兩條命令安裝：

           sudo apt-get install lcov

           sudo apt-get install ggcov

四、將兩者結合使用例項

環境搭建好後可以開心得玩耍了 哈哈

（1）首先了解下我需要測試的程式碼模型：

說明：這是我自己寫的簡單的訊息傳遞及監聽模型測試程式碼。messageModelLib目錄是訊息傳遞模型的核心程式碼，

編譯出來一個.so庫供該目錄的其他模組使用。messageModelLib目錄內容如下：

（2）重點是gtest_lcov目錄，該目錄是專門用來進行單元測試的，目錄內容如下：

說明：gtest_tool 為gtest原始碼的刪減版，lcov-1.11為lcov原始碼包編譯後的目錄，lcov_out為自己建的目錄用來存放lcov工具統計出的結果的輸出。test_case.c為編寫的測試用例，內容如下：

// Copyright 2005, Google Inc.
// All rights reserved.
//
// Redistribution and use in source and binary forms, with or without
// modification, are permitted provided that the following conditions are
// met:
//
//     * Redistributions of source code must retain the above copyright
// notice, this list of conditions and the following disclaimer.
//     * Redistributions in binary form must reproduce the above
// copyright notice, this list of conditions and the following disclaimer
// in the documentation and/or other materials provided with the
// distribution.
//     * Neither the name of Google Inc. nor the names of its
// contributors may be used to endorse or promote products derived from
// this software without specific prior written permission.
//
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

// A sample program demonstrating using Google C++ testing framework.
//
// Author: [email protected] (Zhanyong Wan)


// This sample shows how to write a simple unit test for a function,
// using Google C++ testing framework.
//
// Writing a unit test using Google C++ testing framework is easy as 1-2-3:


// Step 1. Include necessary header files such that the stuff your
// test logic needs is declared.
//
// Don't forget gtest.h, which declares the testing framework.

#include <limits.h>
#include "gtest/gtest.h"

#include "myComDef.h"
#include "responser12.h"
#include "listener12.h"

extern "C" {
	#include "log_out.h"
}



// Step 2. Use the TEST macro to define your tests.
//
// TEST has two parameters: the test case name and the test name.
// After using the macro, you should define your test logic between a
// pair of braces.  You can use a bunch of macros to indicate the
// success or failure of a test.  EXPECT_TRUE and EXPECT_EQ are
// examples of such macros.  For a complete list, see gtest.h.
//
// <TechnicalDetails>
//
// In Google Test, tests are grouped into test cases.  This is how we
// keep test code organized.  You should put logically related tests
// into the same test case.
//
// The test case name and the test name should both be valid C++
// identifiers.  And you should not use underscore (_) in the names.
//
// Google Test guarantees that each test you define is run exactly
// once, but it makes no guarantee on the order the tests are
// executed.  Therefore, you should write your tests in such a way
// that their results don't depend on their order.
//
// </TechnicalDetails>


// Tests Factorial().

// Tests factorial of negative numbers.

static responser1 res1_instance;
static responser2 res2_instance;

static listener1 lis1_instance;
static listener2 lis2_instance;


TEST(apl_registResponserTest, isTrue)
{
	ASSERT_EQ(TRUE, apl_registResponser(RES1, RES_MID, &res1_instance));
       ASSERT_EQ(TRUE, apl_registResponser(RES2, RES_HIGH, &res2_instance));
}


TEST(apl_registListenerTest, isTrue)
{
    ASSERT_EQ(TRUE, apl_registListener(RES1, &res1_instance, &lis1_instance));
    ASSERT_EQ(TRUE, apl_registListener(RES2, &res2_instance, &lis2_instance));
}


TEST(loop_send_test, isRight)
{
    int n = 0;
    while(n < 10)
    {
        MSG_INFO msgInfo;
        char msgData[128];

        msgInfo.resType = RES1;  //設定動作物件
        msgInfo.msg.eventID = R1_FUN1; //設定應該做什麼動作
        EXPECT_EQ(TRUE, apl_sendMessage(RES1, R1_FUN1, msgData)); //傳送開始訊息及動作引數

        //apl_unRegistResponser(RES1);

        msgInfo.msg.eventID = R1_FUN2;
        int a = 10, b = 122;
        apl_msgPacker(msgData,sizeof(int), &a,sizeof(int), &b, -1);
        EXPECT_EQ(TRUE, apl_sendMessage(RES1, R1_FUN2, msgData));

        msgInfo.resType = RES2;
        msgInfo.msg.eventID = R2_FUN1;
        double c = 4.23, d = 2.32;
        apl_msgPacker(msgData,sizeof(double), &c,sizeof(double), &d, -1);
        EXPECT_EQ(TRUE, apl_sendMessage(RES2, R2_FUN1, msgData));

        msgInfo.msg.eventID = R2_FUN2;
        a = 20;
        b = 30;
        apl_msgPacker(msgData,sizeof(int), &a,sizeof(int), &b, -1);
        EXPECT_EQ(TRUE, apl_sendMessage(RES2, R2_FUN2, msgData));

        sleep(1);
        ++n;
    }
}


// Step 3. Call RUN_ALL_TESTS() in main().
//
// We do this by linking in src/gtest_main.cc file, which consists of
// a main() function which calls RUN_ALL_TESTS() for us.
//
// This runs all the tests you've defined, prints the result, and
// returns 0 if successful, or 1 otherwise.
//
// Did you notice that we didn't register the tests?  The
// RUN_ALL_TESTS() macro magically knows about all the tests we
// defined.  Isn't this convenient?

主要測試三個case，訊息迴應者、對應監聽器的註冊和訊息的傳遞和監聽。

編寫好test_case.c以後檔案以後，關鍵的關鍵就是makefile的編寫了，我的makefile是gtest原始碼包example測試makefile基礎上修改的，內容如下：

# A sample Makefile for building Google Test and using it in user
# tests.  Please tweak it to suit your environment and project.  You
# may want to move it to your project's root directory.
#
# SYNOPSIS:
#
#   make [all]  - makes everything.
#   make TARGET - makes the given target.
#   make clean  - removes all files generated by make.

# Please tweak the following variable definitions as needed by your
# project, except GTEST_HEADERS, which you can use in your own targets
# but shouldn't modify.

# Points to the root of Google Test, relative to where this file is.
# Remember to tweak this if you move this file.
GTEST_DIR = ./gtest_tool  #gtest 原始碼所在目錄
XX = g++
CC = gcc
# Where to find user code.
USER_DIR = ..  #測試程式碼所在目錄

# Flags passed to the preprocessor.
# Set Google Test's header directory as a system directory, such that
# the compiler doesn't generate warnings in Google Test headers.
CPPFLAGS += -isystem $(GTEST_DIR)/include

# Flags passed to the C++ compiler.
CXXFLAGS += -g -Wall -Wextra -pthread
CXXFLAGS2 += -g -Wall -Wextra -pthread -fprofile-arcs -ftest-coverage #多了兩個編譯選項
# All tests produced by this Makefile.  Remember to add new tests you
# created to the list.
TARGET = appMain

# the link library you should change according to your need
LINK_LIB = -L$(USER_DIR)/lib -lSendMsgModel -lpthread -lrt

# All Google Test headers.  Usually you shouldn't change this
# definition.
GTEST_HEADERS = $(GTEST_DIR)/include/gtest/*.h \
                $(GTEST_DIR)/include/gtest/internal/*.h

# House-keeping build targets.

all : $(TARGET)

# Builds gtest.a and gtest_main.a.

# Usually you shouldn't tweak such internal variables, indicated by a
# trailing _.
GTEST_SRCS_ = $(GTEST_DIR)/src/*.cc $(GTEST_DIR)/src/*.h $(GTEST_HEADERS)

# For simplicity and to avoid depending on Google Test's
# implementation details, the dependencies specified below are
# conservative and not optimized.  This is fine as Google Test
# compiles fast and for ordinary users its source rarely changes.
gtest-all.o : $(GTEST_SRCS_)
    g++ $(CPPFLAGS) -I$(GTEST_DIR) -c \
            $(GTEST_DIR)/src/gtest-all.cc

gtest_main.o : $(GTEST_SRCS_)
    g++ $(CPPFLAGS) -I$(GTEST_DIR) -c \
            $(GTEST_DIR)/src/gtest_main.cc

gtest.a : gtest-all.o
    $(AR) $(ARFLAGS) [email protected] $^

gtest_main.a : gtest-all.o gtest_main.o
    $(AR) $(ARFLAGS) [email protected] $^

# Builds a sample test.  A test should link with either gtest.a or
# gtest_main.a, depending on whether it defines its own main()
# function.
    
XX_SOURCES = $(wildcard $(USER_DIR)/myListeners/*.cpp $(USER_DIR)/myResponsers/*.cpp)
CC_SOURCES = $(wildcard $(USER_DIR)/logout/*.c)

XX_OBJECTS = $(patsubst %.cpp,%.o,$(XX_SOURCES))
CC_OBJECTS = $(patsubst %.c,%.o,$(CC_SOURCES))

INCLUDE_DIRS = -I$(USER_DIR)/include -I$(USER_DIR)/myListeners -I$(USER_DIR)/myResponsers -I$(USER_DIR)/logout

TEST_CASE_O = ./test_case.o #gtest 測試案例

 $(TEST_CASE_O) : %.o : %.c
    $(XX) -c $(CPPFLAGS) $< -o [email protected] $(INCLUDE_DIRS)
    
$(CC_OBJECTS) : %.o : %.c
    $(CC) -c $(CXXFLAGS2) $< -o [email protected] $(INCLUDE_DIRS)  #需要用lcov檢視哪個檔案的程式碼覆蓋率，編譯的時候就加上-fprofile-arcs -ftest-coverage編譯選項

$(XX_OBJECTS) : %.o : %.cpp
    $(XX) -c $(CXXFLAGS2) $< -o [email protected] $(INCLUDE_DIRS)

$(TARGET) : $(XX_OBJECTS) $(CC_OBJECTS) $(TEST_CASE_O) gtest_main.a
    $(XX) $(CXXFLAGS2) $^ -o [email protected] $(LINK_LIB)

#刪除程式碼目錄的 *.gcda,*.gcno和*.o檔案
SUBDIRS = $(USER_DIR)/myListeners $(USER_DIR)/myResponsers $(USER_DIR)/logout
GCDA_FILES = $(foreach dir, $(SUBDIRS), $(wildcard $(dir)/*.gcda))
GCNO_FILES = $(foreach dir, $(SUBDIRS), $(wildcard $(dir)/*.gcno))
OBJS_FILES = $(foreach dir, $(SUBDIRS), $(wildcard $(dir)/*.o))

clean :
    rm -rf $(TARGET) gtest.a gtest_main.a *.o *.gcno *.gcda *.info lcov_out/* \
    $(GCDA_FILES) $(GCNO_FILES) $(OBJS_FILES)

執行完後也會在生成gcon檔案的目錄下生成gcda檔案。

（6）最後把測試的命令（1~5）命令寫到run.sh腳本里，執行./run.sh就ok了。

#! /bin/bash
cd ..
make clean
cd ./gtest_lcov
make clean
sudo rm -rf ./lcov_out/*
make
./appMain

./lcov-1.11/bin/lcov -d ../ -t 'appMain' -o'appMain.info' -b . -c
./lcov-1.11/bin/genhtml appMain.info --quiet --output-directory lcov_out--title "appMain"
firefox ./lcov_out/index.html

（7）覆蓋率統計圖表：

至此，gtest單元測試工具和lcov覆蓋率統計工具的結合使用介紹完畢，共同學習進步。