生活需要深度

本次安装的 Cunit 版本为 2.1.3。从下载好 CUnit 2.1.3 源码后，依次输入下述命令构建安装 CUnit。以下都假设 为 /opt/CUnit。这个时候头文件和库文件分别在 /opt/CUnit/include 和 /opt/CUnit/lib 目录下，不过此时不太方便使用，需要我们手动指定头文件搜索路径和库文件搜索路径。现在我们在系统的头文件和库文件搜索路径下创建个软连接解决这个问题。这样整个 CUnit 就安装好了，现在来测试一下。

如果pSuite为NULL，则返回CUE_NOSUITE，如果pTest为NULL，则返回CUE_NOTEST，如果pSuite未激活，则返回CUE_SUITE_INACTIVE，如果pTest不是套件中已注册的测试用例，则返回CUE_TEST_NOT_IN_SUITE，如果pTest未激活，则返回CUE_TEST_INACTIVE。框架维护注册表的所有权，因此当调用CU_cleanup_registry()或CU_initialize_registry()函数之后，该函数返回的指针将会失效。

对于资源有限的环境，比如 C 语言嵌入式系统，常用的单元测试框架会带来大量的资源消耗，并且嵌入式更多侧重功能测试，完善的框架实现并非必要。MinUnit 使用 C 语言编写，非常小型的单元测试框架。编译时未引用头文件中定义的宏函数，并不占会用内存。extremely— 摘自[JTN002 — Jera Design LLC](https://jera.com/techinfo/jtns/jtn002)CUnit 是一个编写、管理和运行 C 语言单元测试架构，会通过静态库链接在用户编写的测试代码中。

BDD（行为驱动开发）自动化测试在软件测试领域一直在发展。随着agile思想在越来越多的项目中推广，以及非开发人员在项目的更多参与，BDD风格的自动化测试被越来越多项目组采纳并实施。BDD（Behavior Driven Development），即行为驱动开发，是敏捷开发技术之一，通过自然语言定义系统行为，以功能使用者的角度，编写需求场景，且这些行为描述可以直接形成需求文档，同时也是测试标准。二、为什么要使用BDD传统模式下，从客户提出需求，到输出产品，我们会经历以下流程：

前言如果你见过我，你可能会知道我是自动化测试的忠实信徒。即使对于小型项目，我也倾向于在早期实施一些测试，对于大型项目，我认为测试是绝对必要的。我可以花很长时间来讲为什么测试很重要，而你应该这样做，但这不是今天的主题。相反，我将介绍为什么我将所有单元测试从Google Test（我之前使用的测试框架）移至Catch，并阐明了我如何做到这一点。在我们开始讨论之前，让我们回顾一下我是如何进入Google Test以及为什么我想首先改变一些东西。一个简短的历史许多月前这篇博文让我对单元测试很感兴趣。鉴于

本文翻译自：https://github.com/google/googletest/blob/master/googlemock/docs/CheatSheet.md一、定义一个模拟类1. 模拟一个正常的类，就是接口类 给： 1 2 3 4 5 6 7 8 classFoo { ... virtual~Foo(); virtualintGetSize()con...

教学Google测试如何打印您的值当测试声明（如EXPECT_EQ）失败时，Google Test会打印参数值以帮助您调试。 它使用用户可扩展值打印机。此打印机知道如何打印内置的C ++类型，native数组，STL容器和任何支持<<运算符的类型。 对于其他类型，它打印值中的原始字节，并希望用户可以计算出来。如前所述，打印机是可扩展的。 这意味着你可以教它做一个更好的工作，打印你的特定类型，而不是转储字节。 要做到这一点，定义<<您的类型： 1 2

一、前言上一篇我们分析了gtest的一些内部实现，总的来说整体的流程并不复杂。本篇我们就尝试编写一个精简版本的C++单元测试框架：nancytest ，通过编写这个简单的测试框架，将有助于我们理解gtest。二、整体设计使用最精简的设计，我们就用两个类，够简单吧：1. TestCase类包含单个测试案例的信息。2. UnitTest类负责所有测试案例的执行，管理。三、TestCase类TestCase类包含一个测试案例的基本信息，包括：测试案例名称，测试案例执行结果，同时还

一、前言“深入解析”对我来说的确有些难度，所以我尽量将我学习到和观察到的gtest内部实现介绍给大家。本文算是抛砖引玉吧，只能是对gtest的整体结构的一些介绍，想要了解更多细节最好的办法还是看gtest源码，如果你看过gtest源码，你会发现里面的注释非常的详细！好了，下面就开始了解gtest吧。二、从TEST宏开始前面的文章已经介绍过TEST宏的用法了，通过TEST宏，我们可以非法简单、方便的编写测试案例，比如：TEST(FooTest,Demo){EXPECT_EQ(1,...

一、前言使用gtest编写的测试案例通常本身就是一个可执行文件，因此运行起来非常方便。同时，gtest也为我们提供了一系列的运行参数（环境变量、命令行参数或代码里指定），使得我们可以对案例的执行进行一些有效的控制。二、基本介绍前面提到，对于运行参数，gtest提供了三种设置的途径：1. 系统环境变量2. 命令行参数3. 代码中指定FLAG因为提供了三种途径，就会有优先级的问题， 有一个原则是，最后设置的那个会生效。不过总结一下，通常情况下，比较理想的优先级为：命令行参数 &g

gtest提供了多种事件机制，非常方便我们在案例之前或之后做一些操作。总结一下gtest的事件一共有3种：1. 全局的，所有案例执行前后。2. TestSuite级别的，在某一批案例中第一个案例前，最后一个案例执行后。3. TestCase级别的，每个TestCase前后。1. 全局事件要实现全局事件，必须写一个类，继承testing::Environment类，实现里面的SetUp和TearDown方法。1. SetUp()方法在所有案例执行前执行2. TearDown()方法

一、前言“死亡测试”名字比较恐怖，这里的“死亡”指的的是程序的崩溃。通常在测试过程中，我们需要考虑各种各样的输入，有的输入可能直接导致程序崩溃，这时我们就需要检查程序是否按照预期的方式挂掉，这也就是所谓的“死亡测试”。gtest的死亡测试能做到在一个安全的环境下执行崩溃的测试案例，同时又对崩溃结果进行验证。二、使用的宏Fatal assertion Nonfatal assertion Verifies ASSERT_DEATH(statement, regex`); EX

一、测试夹具(Test Fixtures)：对多个测试使用相同的数据配置如果你发现自己写了两个或更多的测试来操作类似的数据，你可以使用测试夹具。它允许您为几个不同的测试重复使用相同的对象配置。要创建夹具，只需： 1.从:: testing :: Test派生一个类。 使用protected：或public：开始它的主体，因为我们想从子类 访问fixture成员。 2.在类中，声明你打算使用的任何对象。 3.如果需要，可以编写默认构造函数或SetUp（）函数来为每个测试准备对象。...

一、前言在设计测试案例时，经常需要考虑给被测函数传入不同的值的情况。我们之前的做法通常是写一个通用方法，然后编写在测试案例调用它。即使使用了通用方法，这样的工作也是有很多重复性的，程序员都懒，都希望能够少写代码，多复用代码。Google的程序员也一样，他们考虑到了这个问题，并且提供了一个灵活的参数化测试的方案。二、旧的方案为了对比，我还是把旧的方案提一下。首先我先把被测函数IsPrime帖过来(在gtest的example1.cc中)，这个函数是用来判断传入的数值是否为质数的。//Re.

单元测试的基本理论

C++单元测试1 gtest是什么gtest是Google开发的一个开源单元测试框架，git仓库点击这里获取。主要针对c/c++，gtest有如下特点：提供强大的断言集，支持包括布尔、整型、浮点型、字符串等提供断言方法自定义扩展自动收集测试用例，无需开发者再次组织提供死亡测试功能可以将公共的用例初始化和清理工作放入测试夹具中，由gtest自动调用使用参数化自动生成多个相似的测试用例2 gtest的获取和编译在GitHub上获取当前最新的gtest源码，我这里使用的是v1.8.1版本，

在金字塔模型之前，流行的是冰淇淋模型。包含了大量的手工测试、端到端的自动化测试及少量的单元测试。造成的后果是，随着产品壮大，手工回归测试时间越来越长，质量很难把控；自动化case频频失败，每一个失败对应着一个长长的函数调用，到底哪里出了问题？单元测试少的可怜，基本没作用。Mike Cohn 在他的着作《Succeeding with Agile》一书中提出了“测试金字塔”这个概念。这个比喻非常形象，它让你一眼就知道测试是需要分层的。它还告诉你每一层需要写多少测试。 测试金字塔本身是一条很好的经验法则

Cmockery是Google给出的C语言单元测试框架。1、cmockery库源码的编译链接下载链接：https://code.google.com/p/cmockery/downloads/list下载需要FQ，没有条件的可以直接在github上找一篇比较完整的版本。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

什么是单元测试单元测试是软件开发过程中的一种质量保证手段。最初的来源是想模仿对硬件芯片做单元测试那样，在软件中也能对小的软件单元进行测试，从而保证软件中某个局部设计的正确性。传统的单元测试定义传统软件单元测试将被测单元的粒度规定为软件中最小的功能模块。对于C语言通常指一个函数，对于Java或者C++语言通常指一个类。传统做法是针对被测单元的实现细节进行各种白盒测试，即针对被测代码的实现逻辑进行各种分支测试和覆盖测试。传统的单元测试由于缺乏自动化工具的支持，往往在测试中通过打印输出测试结果

软件测试是伴随着软件开发的全流程，具体过程包含单元测试（接口测试）、联调测试、冒烟测试。集成测试、领域测试、系统测试、交付测试。集成测试一般情况下包含手工和自动化两部分，其中自动化测试和手工测试同步协作，手工测试流程会将成熟的手工流程逐步完善自动化测试内容，而自动化测试可以有效的保证每一项开发功能不会有其他边际的功能被影响到，将手工测试工作集中在本次需要交付的特定功能上面。...