UnitTest++简介

Posted on 2016-02-29 Edited on 2016-06-08

~~Edit~~

UnitTest++简介

最近拜读了Kent Beck大神的《Test-Driven Development By Example》，有了这篇读书笔记。这本书解答了我的很多开发中遇到的困惑，所以决定以后走上TDD的道路。那为什么会学习UnixTest++，其实是因为惠普打印机的Phoenix FW里面曾经有先辈做过类似unit test的事情，称之为Linux Test Harness。Harnes是马鞍的意思，这个名字应该是惠普人自己取的。这个Linux Test Harness就是基于UnixTest++的。目前我用的是最新版，v1.5.1。目录树结构如下：
├── AUTHORS
├── CMakeLists.txt
├── ChangeLog
├── INSTALL
├── LICENSE
├── Makefile.am
├── README.md
├── UnitTest++
├── UnitTest++.pc.in
├── appveyor.yml
├── builds
├── configure.ac
├── docs
├── m4
│ ├── ax_cxx_compile_stdcxx.m4
│ └── ax_cxx_compile_stdcxx_11.m4
└── tests

7 directories, 95 files
重要的文件或文件夹我标成了红色。

CMakeLists.txt
- UnitTest++是基于CMake的，后面会具体讲CMake，这个文件就类似于CMake的工程文件。CMake基于它生成Makefile或者其他开发平台的工程文件。
UnitTest++
- UnitTest++是开源项目，这个文件夹就是UnitTest++所有的源码
tests
- 这个是UnitTest++本身的test case。我们在写自己的test case的时候完全可以参考别人是怎么写的。

CMake

这里收集了两篇CMake的文章，CMake使用总结和CMake 入门实战
CMake意为Cross-platform Make，可用于管理C/C++工程。你或许听过好几种 Make 工具，例如 GNU Make ，QT 的 qmake ，微软的 MS nmake，BSD Make（pmake），Makepp，等等。这些 Make 工具遵循着不同的规范和标准，所执行的 Makefile 格式也千差万别。这样就带来了一个严峻的问题：如果软件想跨平台，必须要保证能够在不同平台编译。而如果使用上面的 Make 工具，就得为每一种标准写一次 Makefile ，这将是一件让人抓狂的工作。就是针对这个问题所设计的工具。它首先允许开发者编写一种平台无关的 CMakeList.txt 文件来定制整个编译流程，然后再根据目标用户的平台进一步生成所需的本地化 Makefile 和工程文件，如 Unix 的 Makefile 或 Windows 的 Visual Studio 工程。从而做到“Write once, run everywhere”。
在 linux 平台下使用 CMake 生成 Makefile 并编译的流程如下：

编写 CMake 配置文件 CMakeLists.txt 。
执行命令cmake -G "Unix Makefiles" <PATH>生成Unix识别的Makefile[^support]，<PATH>是 CMakeLists.txt 所在的目录。也可以用ccmake，ccmake 和 cmake 的区别在于前者提供了一个交互式的界面。
使用 make 命令进行编译。
以UnitTest++自带的CMakeLists.txt为例：

cmake_minimum_required(VERSION 2.8.1)
project(UnitTest++)

# get the main sources
file(GLOB headers_ RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} UnitTest++/*.h)
file(GLOB sources_ RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} UnitTest++/*.cpp)
source_group("" FILES ${headers_} ${sources_})

# get platform specific sources
if (WIN32)
    add_definitions(-D_CRT_SECURE_NO_DEPRECATE)
    set(platformDir_ Win32)
else()
    set(platformDir_ Posix)
endif(WIN32)

file(GLOB platformHeaders_ RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} UnitTest++/${platformDir_}/*.h)
file(GLOB platformSources_ RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} UnitTest++/${platformDir_}/*.cpp)
source_group(${platformDir_} FILES ${platformHeaders_} ${platformSources_})

# create the lib
add_library(UnitTest++ STATIC ${headers_} ${sources_} ${platformHeaders_} ${platformSources_})

# build the test runner
file(GLOB TEST_SRCS RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} tests/*.cpp tests/*.h)
source_group( "" FILES ${TEST_SRCS})
add_executable(TestUnitTest++ ${TEST_SRCS})
include_directories(.)

if(${UTPP_USE_PLUS_SIGN})
    set_target_properties(TestUnitTest++ PROPERTIES OUTPUT_NAME TestUnitTest++)
endif()

target_link_libraries(TestUnitTest++ UnitTest++)

# run unit tests as post build step
add_custom_command(TARGET TestUnitTest++
    POST_BUILD COMMAND TestUnitTest++
    COMMENT "Running unit tests")

set, file, add_library等等都是命令，具体命令可以参考这个笔记CMake使用总结。

add_library(UnitTest++…)将UnitTest++代码编译成静态库
add_executable(TestUnitTest++ …)生成UnitTest++应用文件
target_link_libraries(TestUnitTest++ UnitTest++)将前面生成的libUnitTest++.a链入TestUnitTest++可执行文件。
add_custom_command(TARGET TestUnitTest++…)这一行决定了运行make时，额外调用的命令。

CMake使用总结这篇笔记里提到：

按照官方文档的说法，不建议使用file的GLOB指令来收集工程的源文件，原文解释如下
We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate.
大意就是，GLOB收集的源文件增加或删除，而CMakeLists.txt没有发生修改时，CMake不能识别这些文件。其实，当CMakeLists.txt使用aux_source_directory和file glob查找工程源文件时，如果添加或删除源文件，都需要重新运行CMake。

cmake 如何编出可以GDB的程序？

cmake -DCMAKE_BUILD_TYPE=Debug CMakeList.txt

Implement Test Cases

Test Case的编写通过UnixTest++本身的宏引入：

    SUITE(MyUnitTests)
    {
        TEST(StarterTest)
        {
            MonoGraphCpInit(false);
            CHECK(true);
        }
    }

运行make之后的输出为：

Running unit tests
Success: 2 tests passed.
Test time: 7.54 seconds.
[100%] Built target MyTest

TEST宏引入的就是一个test case，SUITE宏引入的是一个测试套件。默认情况下，所有用SUITE或者TEST定义的case都会被运行，看main code。

int main(int, const char *[])
{
   return UnitTest::RunAllTests();
}

因为我们有UnitTest++的源码，其实想怎么测都可以。经过学习，如果想调用指定case的main code可以如下编写：

   UnitTest::TestReporterStdout reporter;
   UnitTest::TestRunner runner(reporter);
   return runner.RunTestsIf(UnitTest::Test::GetTestList(), "MyUnitTests", UnitTest::True(), 0);

这段code调用了名字叫MyUnitTests的SUITE中所有case。

Linux Test Harness

Phoenix FW里面的Linux Test Harness是基于UnixTest++的。可以参考components/GCP/JsonDataModel/linux_test_harness/Makefile。其中用到的UnixTest++是v1.4的，并没有用到cmake来构建。而是自己构建的Makefile来编译。运用最新的cmake来搭建Unit Test环境感觉更简单，而且竟然还能有平台移植性，虽然目前对我们没用，不过还是很赞的。将UnixTest++编译到可用还是挺简单的，但是要整合Phoenix code有那么一点麻烦。先讲一下我们的使用场景，测试Mono Graphic Panel Driver。再将具体搭建的思路和一些小tips。

Mono Graphic Panel Driver

这里有一篇相关笔记Pheonix_Display。我其实想做的是在Mono Graphic Panel Driver中添加一个Recovery Thread。先看下源码架构：

[benzhou@plslx111 phx]$ ls components/bsp/control_panel/
abc buttonLed ccpi clcd inc monoGraph obj pub src

monoGraph中的代码会调用到abc文件夹下的代码。所以linux_test_harness就放在这个文件夹下。并且abc和monoGraph中的代码需要被链接到我们的测试程序中。

测试架构

最后我们的CMakeLists.txt如下：

cmake_minimum_required(VERSION 2.8.1)
project(MyTest)

set(CMAKE_C_COMPILER "g++")

# enable gdb
set(CMAKE_BUILD_TYPE "Debug")
set(CMAKE_CXX_FLAGS_DEBUG "$ENV{CXXFLAGS} -O0 -Wall -g -ggdb")
set(CMAKE_CXX_FLAGS_RELEASE "$ENV{CXXFLAGS} -O3 -Wall")

set(PHX_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../../../../../")

include_directories(..)
include_directories(stubs)
include_directories(${PHX_DIR}components/bsp/control_panel/monoGraph/pub/)
include_directories(${PHX_DIR}components/bsp/control_panel/monoGraph/inc/)
include_directories(${PHX_DIR}components/bsp/control_panel/abc/pub/)
include_directories(${PHX_DIR}components/bsp/control_panel/abc/inc/)
include_directories(${PHX_DIR}components/bsp/control_panel/pub/)
include_directories(${PHX_DIR}components/bsp/control_panel/inc/)
include_directories(${PHX_DIR}components/primboot/pub/)

# get Phoenix code
#file(GLOB PHX_SRCS RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} ../../../src/*.cpp ../../../src/*.c)
aux_source_directory(${PHX_DIR}/components/bsp/control_panel/abc/src PHX_ABC)
aux_source_directory(${PHX_DIR}/components/bsp/control_panel/monoGraph/src PHX_MONO)
list(APPEND PHX_SRCS
    ${PHX_ABC}
    ${PHX_MONO}
)
add_library (PhxFunctions STATIC ${PHX_SRCS})

# get the Phoenix stub sources
aux_source_directory(${PHX_DIR}/components/bsp/control_panel/linux_test_harness/mytests/stubs PHX_STUBS)
add_library (StubFunctions STATIC ${PHX_STUBS})

# get the main sources
aux_source_directory(${PHX_DIR}/components/bsp/control_panel/linux_test_harness/mytests TEST_SRCS)

add_executable(MyTest ${TEST_SRCS})

target_link_libraries(MyTest
    pthread
    UnitTest++
    PhxFunctions
    StubFunctions
)

# run unit tests as post build step
add_custom_command(TARGET MyTest
    POST_BUILD COMMAND MyTest
    COMMENT "Running unit tests"
)

除了UnitTest++框架本身的库libUnitTest++.a和链入了一个pthread库以外，我们还定义了另外两个库PhxFunctions和StubFunctions。

PhxFunctions是我们想测试的code，即abc和monoGraph文件夹
StubFunctions是为了编译通过，定义的一些存根函数

主要需要注意的是怎么定义这些存根文件和函数。根据我的经验和TDD思想(不要为了明天设计)，应该注意：

如果有找不到的头文件，在stubs文件夹里加一个空文件
如果有找不到的类声明，从FW找到类定义拷贝过来
如果有找不到定义的函数的链接错误，就在stub.cpp中定义空函数。
如果将来发现需要调用真实的FW函数，就需要将那个函数所在的源码文件编译成库链接进来。