使用VisualStudio2022年进行C++单元测试

使用 Visual Studio 进展 C++单元测试

什么是单元测试？单元测试〔unit testing〕在软件开发领域有着悠久的历史。在大多数有关单元测试的观念中都有这么一个共同的理念，即它们由一组独立的测试构成，其中每个测试针对一个单独的软件组件。在过程式程序设计的代码中，“单元”一般来说指的就是函数，而在面对对象的代码中则指的是类。

而单元测试则做到了大型测试所不能做到的那些事情。利用单元测试可以独立地对某一段代码进展测试。我们可以将测试分组以便在某些特定条件下运行某些特定的测试，并在其他条件下运行另一些测试。我们还可以快速定位错误。假设认为在某段代码中存在着一个错误而且又可以在测试用具中使用这段代码的话，我们通常能够快速地编写出一段测试，看看我们所推想的错误是不是真的在那里。

〔一〕关于单元测试的一些流行误会〔反面即为单元测试的好处〕

1. 单元测试是在铺张时间

一旦编码完成， 开发人员总是会迫切期望进展软件的集成工作，这样他们就能够看到实际的系统开头启开工作了。 这在外表上看来是一项明显的进步，而象单元测试这样的活动或许会被看作是通往这个阶段点的道路上的障碍， 推迟了对整个系统进展联调这种真正有意思的工作启动的时间。

在这种开发步骤中，真实意义上的进步被外表上的进步取代了。系统能够正常工作的可能性是很小的，

更多的状况是布满了各式各样的 Bug。在实践中，这样一种开发步骤经常会导致这样的结果：软件甚至无法运行。

更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简洁的 Bug 上面，在个别状况

下，这些 Bug 或许是琐碎和微缺乏道的，但是总的来说，他们会导致在软件集成为一个系统时增加额外的工期，而且当这个系统投入使用时也无法确保它能够牢靠运行。

在实践工作中，进展了完整打算的单元测试和编写实际的代码所花费的精力大致上是一样的。一旦完成了这些单元测试工作，很多 Bug 将被订正，在确信他们手头拥有稳定牢靠的部件的状况下，开发人员能够进展更高效的系统集成工作。这才是真实意义上的进步，所以说完整打算下的单元测试是对时间的更高效的利用。而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。

点评：假设产品的规模格外小(例如小工具)，并且产品的质量不重要(或无所谓)，那么“单元测试是在铺张时间”这样的说法在某种程序上是正确的。

假设产品质量格外重要，那么就意味着即使你不在单元测试阶段投入时间觉察并修改 bug，存在的 bug

也会在后续的阶段被觉察，需要说明的是bug 觉察得越晚，修改它所付出的代价越大。这样违反原则：尽早觉察并修改 bug，以削减软件开发本钱。

2. 单元测试仅仅是证明这些代码做了什么

这是那些没有首先为每个单元编写一个具体的规格说明而直接跳到编码阶段的开发人员提出的一条普

遍的埋怨，当编码完成以后并且面临代码测试任务的时候，他们就阅读这些代码并找出它实际上做了什么，

把他们的测试工作基于已经写好的代码的根底上。固然，他们无法证明任何事情。全部的这些测试工作能够说明的事情就是编译器工作正常。是的，他们或许能够抓住(期望能够)罕见的编译器 Bug，但是他们能够做

的仅仅是这些。假设他们首先写好一个具体的规格说明，测试能够以规格说明为根底。代码就能够针对它的规格说明，而不是针对自身进展测试。这样的测试仍旧能够抓住编译器的Bug，同时也能找到更多的编码错误，甚至是一些规格说明中的错误。 好的规格说明可以使测试的质量更高，所以最终的结论是高质量的测试需要高质量的规格说明。在实践中会消灭这样的状况：一个开发人员要面对测试一个单元时只给出单元的代码而没有规格说明这样吃力不讨好的任务。你怎样做才会有更多的收获，而不仅仅是觉察编译器的Bug？ 第一步是理解这个单元原本要做什么，不是它实际上做了什么。比较有效的方法是倒推出一个概要的规格说明。这个过程的主要输入条件是要阅读那些程序代码和注释，主要针对这个单元，及调用它和被它调用的相关代码。画出流程图是格外有帮助的，你可以用手工或使用某种工具。可以组织对这个概要规格说明的走读(Review)，以确保对这个单元的说明没有根本的错误，有了这种最小程度的代码深层说明，就可以用它来设计单元测试了。

点评：合理的单元测试不仅可以保证单元代码正确实现，还可以在编码过程中用来调试单元代码、以及随时了解单元测试掩盖了多少单元代码。

3. 我是个很棒的程序员， 我是不是可以不进展单元测试？

在每个开发组织中都至少有一个这样的开发人员，他格外擅长于编程，他们开发的软件总是在第一时间就可以正常运行，因此不需要进展测试。你是否经常听到这样的借口？

在真实世界里，每个人都会犯错误。即使某个开发人员可以抱着这种态度在很少的一些简洁的程序中应付过去。但真正的软件系统是格外简单的。真正的软件系统不行以寄期望于没有进展广泛的测试和 Bug 修改正程就可以正常工作。

编码不是一个可以一次性通过的过程。在真实世界中，软件产品必需进展维护以对操作需求的转变作出反响，并且要对最初的开发工作遗留下来的 Bug 进展修改。你期望依靠那些原始作者进展修改吗？这些制造出这些未经测试的原始代码的资深专家们还会连续在其他地方制造这样的代码。在开发人员做出修改后进展可重复的单元测试可以避开产生那些令人不快的负作用。

点评：我成认你是一个很棒的程序员，你很少犯错误。但很少犯错误不等于不犯错误，并且你的代码一

定有其他人维护的时候(比方你离职了)。试问一下，当其他人修改你写的代码的时候，怎样才能保证他修改后的正确性呢？因此，答案是显而易见地。

4. 不管怎样，集成测试将会抓住宅有的 Bug

我们已经在前面的争辩中从一个侧面对这个问题进展了局部的阐述。这个论点不成立的缘由在于规模越大的代码集成意味着简单性就越高。假设软件的单元没有事先进展测试，开发人员很可能会花费大量的时间仅仅是为了使软件能够运行，而任何实际的测试方案都无法执行。一旦软件可以运行了，开发人员又要面对这样的问题：在考虑软件全局简单性的前提下对每个单元进展全面的测试。这是一件格外困难的事情，甚至在制造一种单元调用的测试条件的时候，要全面的考虑单元的被调用时的各种入口参数。

在软件集成阶段， 对单元功能全面测试的简单程度远远的超过独立进展的单元测试过程。最终的结果

是测试将无法到达它所应当有的全面性。一些缺陷将被遗漏，并且很多 Bug 将被无视过去。

让我们类比一下，假设我们要清洗一台已经完全装配好的食物加工机器！无论你喷了多少水和清洁剂，

一些食物的小碎片还是会粘在机器的死角位置，只有任其腐烂并等待以后再想方法。但我们换个角度想想，

假设这台机器是拆开的，这些死角或许就不存在或者更简洁接触到了，并且每一局部都可以毫不费力的进展

清洗。

点评：假设每个开发人员都这样想，那么集成测试有可能进展不下去了，例如：系统集成后格外简洁崩溃，无法进展测试。

另外，即使能够进展正常测试，需要说明的是bug 觉察得越晚，修改它所付出的代价越大。这样违反原则：尽早觉察并修改 bug，以削减软件开发本钱。

5. 单元测试的本钱效率不高

一个特定的开发组织或软件应用系统的测试水平取决于对那些未觉察的 Bug 的潜在后果的重视程度。这种后果的严峻程度可以从一个 Bug 引起的小小的不便到发生屡次的死机的状况。这种后果可能经常会被软件的开发人员所无视(但是用户可不会这样)，这种状况会长期的损害这些向用户提交带有 Bug 的软件的开发组织的信誉，并且会导致对将来的市场产生负面的影响。相反地，一个牢靠的软件系统的良好的声誉将有助于一个开发组织猎取将来的市场。

很多争辩成果说明， 无论什么时候做出修改都要进展完整的回归测试， 在生命周期中尽早地对软件产品进展测试将使效率和质量得到最好的保证。Bug 觉察的越晚，修改它所需的费用就越高，因此从经济角度来看，应当尽可能早的查找和修改 Bug。在修改费用变的过高之前，单元测试是一个在早期抓住 Bug 的时机。

相比后阶段的测试，单元测试的创立更简洁，维护更简洁，并且可以更便利的进展重复。从全程的费用来考虑，相比起那些简单且旷日长久的集成测试，或是不稳定的软件系统来说， 单元测试所需的费用是很低的。

点评：单元测试是一个在早期抓住 bug 的时机，符合原则：尽早觉察并修改 bug，以削减软件开发本钱。

〔二〕单元测试不能做什么

1. 单元测试解决不了设计失误带来的问题，即使最低劣的设计也可能通过单元测试。

2. 单元测试解决不了由于设计和编码不当带来的性能问题。

3. 单元测试不能解决产品的可用性和易用性问题。

4. 单元测试通常不能解决类和类的一些规律问题。

5. 单元测试不能用来测试需要很长时间才能完成的操作(例如：数据连接超时)。

〔三〕好的单元测试(Visual Studio) 标准

1. 单元测试应当在最低的功能/参数上验证程序的正确性

单元测试应当测试程序中最根本的单元，如C#中的类。〔作为扩展来说，也可以适当测试一些类与类之间简洁的规律〕

2. 单元测试应当由最生疏代码的人(程序的作者)来写

3. 单元测试过后，机器状态保持不变

这样就可以重复不断地运行单元测试，例如：假设单元测试创立了一些临时文件或名目，应当在

Teardown 阶段将它们删除。

4. 单元测试应当要快

5. 单元测试应当产生可重复的、全都的结果

6. 独立性，单元测试的运行/通过/失败不依靠于别的测试，可以人为构造数据，以保持单元测试的独立性

7. 单元测试应当掩盖全部代码路径，包括错误处理路径

8. 单元测试应当集成到自动测试的框架中

单元测试自动化后，这样每个人都能很简洁地运行它，并且每天都可以自动运行。

9. 单元测试必需和产品代码一起保存和维护

〔四〕怎样进展 C++单元测试

1. 创立 Win32_dll 工程，该工程模拟待测试的 Win32 动态连接库工程

a) 启动 Visual Studio 2022，选择[文件] -> [建] -> [工程]，进入如以下图界面：

b) 按上图中的命名输入，点击[确定]，进入下面的界面：

c)

点击[完成]，生成 Win32 的动态连接库(DLL)工程 Win32_dll。

d) 翻开Win32_，增加几个单元用于演示单元测试，增加之后的 Win32_ 文件内容如下(红色粗体局部表示增加内容)：

// Win32_ : 定义DLL 应用程序的导出函数。

//

#include “stdafx.h“

declspec(dllexport) int add(int a, int b)

{

return a + b;

}

declspec(dllexport) int sub(int a, int b)

{

return a - b;

}

class

{

public:

int add_or_sub(int a, int b, BOOL is_add);

};

int calc::add_or_sub(int a, int b, BOOL is_add)

{

if(is_add)

declspec(dllexport) calc

{

return a + b;

}

return a - b;

}

e) 这样，待测试的 Win32_dll 工程就完成了。

f) 为了能够运行、统计 Win32_dll 工程的代码掩盖率，对其进入如下设置：选择 Win32_dll 工程 -> 右键菜单 -> 属性 -> 进入如下界面：

g) 按上图进展设置，点击[确定]即可。

h) 编译 Win32_dll 工程,在解决方案名目下的 Debug 名目(本例为 e:testCppUnitTestDebug)中生成了 Win32_ 和 Win32_。

2. 创立 MFC_dll 工程，该工程模拟待测试的 MFC 动态连接库工程

a) 右键点击[解决方案] -> [添加] -> [建工程]，进入如以下图界面：

b) 按上图进展设置，点击[确定]，进入下面的界面：

c) 点击[完成]，生成 MFC 的动态连接库(DLL)工程 MFC_dll。

d) 右键点击[工程 MFC_dll]下的[源文件] -> [添加] -> [建工程]消灭如下的界面：

e) 点击[添加] -> 工程中生成了 ，文件内容为空。

f) 翻开 ，增加一个 MyPtrList 类用于演示单元测试，增加之后的 文件内容如下(红色粗体局部表示增加内容)：

#include “stdafx.h“

class

{

public:

MyPtrList(int nBlockSize);

};

MyPtrList::MyPtrList(int nBlockSize) : CPtrList(nBlockSize)

{

}

declspec(dllexport) MyPtrList : public CPtrList

g) 这样，待测试的 MFC_dll 工程就完成了。

h) 为了能够运行、统计该工程的代码掩盖率，对该工程进入如下设置：选择 MFC_dll 工程 -> 右键属性 -> 进入如下界面：

i) 按上图进展设置，点击[确定]即可。

j) 编译 MFC_dll 工程,在解决方案名目下的 Debug 名目(本例为 e:testCppUnitTestDebug)中生成了 MFC_ 和 MFC_。

3. 创立单元测试工程 MyUnitTest，用于测试 Win32_dll 工程和 MFC_dll 工程中的单元代码

a) 选项 Visual Studio 菜单[测试] -> [建测试] -> 进入如以下图界面：

b) 点击[确定] -> 弹出建测试工程 -> 输入 MyUnitTest，点击[创立] ，生成了单元测试工程MyUnitTest。

c) 右 键 点 击 [ 项 目 MyUnitTest] 下 的 [ 源 文 件 ] -> [ 添 加 ] -> [ 已 有 项 目 ] ， 选 择

e:testCppUnitTestDebug下的 Win32_ 和 MFC_，选择不需要生成规章即可。

d) 翻开 stdafx.h，增加下面的内容(红色粗体局部表示增加内容，特别说明：增加内容以后，stdafx.h

的内容和生成的 MFC 应用程序中的 stdafx.h 内容完全一样)：

// stdafx.h : 标准系统包含文件的包含文件，

// 或是经常使用但不常更改的

// 工程特定的包含文件

#pragma once

#ifndef VC_EXTRALEAN

#define VC_EXTRALEAN

#endif

// 从Windows 标头中排解不常使用的资料

// 假设您必需使用以下所指定的平台之前的平台，则修改下面的定义。

// 有关不同平台的相应值的最信息，请参考MSDN。

#ifndef WINVER

#define WINVER 0x0400

#endif

// 允许使用Windows 95 和Windows NT 4 或更高版本的特定功能。

//为Windows98 和Windows 2022 及更版本转变为适当的值。

#ifndef _WIN32_WINNT // 允许使用Windows NT 4 或更高版本的特定功能。

//为Windows98 和Windows 2022 及更版本转变为适当的值。 #define _WIN32_WINNT 0x0400

#endif

#ifndef _WIN32_WINDOWS

#endif

// 允许使用Windows 98 或更高版本的特定功能。

#define _WIN32_WINDOWS 0x0410 // 为Windows Me 及更版本转变为适当的值。

#ifndef _WIN32_IE

#endif

// 允许使用IE 4.0 或更高版本的特定功能。

#define _WIN32_IE 0x0400 //为IE 5.0 及更版本转变为适当的值。

#define _ATL_CSTRING_EXPLICIT_CONSTRUCTORS // 某些CString 构造函数将是显式的

// 关闭MFC 对某些常见但经常被安全无视的警告消息的隐蔽

#define _AFX_ALL_WARNINGS

#include

#include

// MFC 核心和标准组件

// MFC 扩展

// Internet Explorer 4 公共控件的MFC 支持 #include

#ifndef _AFX_NO_AFXCMN_SUPPORT

#include // Windows 公共控件的MFC 支持

#endif // _AFX_NO_AFXCMN_SUPPORT

e) 翻开 TestWin32_，增加几个单元测试，增加之后的TestWin32_ 文件内容如下(红色粗体局部表示增加内容)：

#include “stdafx.h“

declspec(dllimport) int add(int a, int b);

declspec(dllimport) int sub(int a, int b);

class

{

public:

int add_or_sub(int a, int b, BOOL is_add);

};

class

{

public:

MyPtrList(int nBlockSize);

};

declspec(dllimport) calc

declspec(dllimport) MyPtrList : public CPtrList

using namespace System;

using namespace System::Text;

using namespace System::Collections::Generic;

using namespace Microsoft::VisualStudio::TestTools::UnitTesting;

namespace MyUnitTest

{

[TestClass]

public ref class TestWin32_dll

{

private:

TestContext^ testContextInstance;

public:

///

property Microsoft::VisualStudio::TestTools::UnitTesting::TestContext^ TestContext

{

Microsoft::VisualStudio::TestTools::UnitTesting::TestContext^ get

{

return testContextInstance;

}

System::Void set(Microsoft::VisualStudio::TestTools::UnitTesting::TestContext^ value)

{

testContextInstance = value;

}

};

#pragma region Additional test attributes

//

//编写测试时，还可使用以下附加属性:

//

//在运行类中的第一个测试之前，使用ClassInitialize 来运行代码

//[ClassInitialize]

//static void MyClassInitialize(TestContext^ testContext) {};

//

//在类中的全部测试都已运行之后，使用ClassCleanup 来运行代码

//[ClassCleanup]

//static void MyClassCleanup {};

//

//在运行每个测试之前，使用TestInitialize 来运行代码

//[TestInitialize]

//void MyTestInitialize {};

//

//在每个测试运行完之后，使用TestCleanup 来运行代码

//[TestCleanup]

//void MyTestCleanup {};

//

#pragma endregion

[TestMethod]

void TestAdd

{

Assert::AreEqual(add(1,2), 3);

};

[TestMethod]

void TestSub

{

Assert::AreEqual(sub(1,2), -1);

};

[TestMethod]

void TestAddOrSub

{

calc c;

Assert::AreEqual(_or_sub(1, 2, TRUE), 3);

Assert::AreEqual(_or_sub(1, 2, FALSE), -1);

};

[TestMethod]

void TestMyPtrList

{

int a = 123;

MyPtrList list(3);

Assert::AreEqual(nt, 0);

l(&a);

Assert::AreEqual(nt, 1); POSITION

pos = dPosition;

Assert::IsTrue(pos != NULL);

Assert::AreEqual(*(int *)((pos)), 123);

All;

};

};

}

f) 这样，单元测试工程 MyUnitTest 工程就完成了。

g) 为了能够运行、统计该 Win32_dll 工程和MFC_dll 工程的代码掩盖率，对设置：选择 MyUnitTest 工程 -> 右键属性 -> 进入如下界面：

MyUnitTest 工程进入如下

为了支持 MFC 和混和型单元测试工程，按以下图进展设置：

h) 点击[确定]完成 MyUnitTest 工程配置。

i) 选 择 Visual Studio 菜 单 [ 测 试 ] -> [ 编 辑 测 试 运 行 配 置 ] -> 本 地 测 试 运 行

(nconfig)按以下图进展选择，表示要对 MFC_ 和 Win32_ 进展代码掩盖统计：

j) 按挨次重生成 Win32_dll 工程、MFC_dll 工程、MyUnitTest 工程，这样全部工程就生成成功了。

4. 调试和在本地运行单元测试

a) 设置 MyUnitTest 工程为启开工程。

b) 你可以在需要调试的地方设置断点，之后就可以 F5 进展调试，并观看本地运行结果。

5. 查看代码掩盖率

a) 选择 Visual Studio 菜单[测试] -> [运行] -> [解决方案中的全部测试] -> 结果如以下图所示：