我有兴趣听到有关使用Visual Studio 2005总体上使用TDD和C ++进行单元测试的经验的信息(专业)

首先介绍一些背景。我们有一个相当大的项目，其中许多项目是在Linux上使用CppUnit进行单元测试而开发的。该项目分为几个库，每个库都有自己的一组测试。我有一个简单的脚本，可以编译库，编译测试套件，然后运行测试。因此，在更改代码后，我仅从命令行运行"测试"，然后运行测试。

现在，大多数开发人员都在Windows上使用Visual Studio 2005来开发此产品。当然，他们仍然可以使用nmake从命令行运行测试，但是涉及额外的步骤，我希望有一个更加集成的解决方案。

所以我的问题分为两部分。

首先，在大型代码库上布局测试代码的最佳方法是什么？在解决方案中创建多个测试项目，每个库一个，这是正常的吗？

其次，是否有用于将CppUnit测试集成到Visual Studio中的工具？设置了依赖项后，可以正常运行测试项目，但应该运行测试，但当前结果仍显示在命令窗口中。

解决方案

我的团队目前正在使用一个系统，该系统具有每晚自动生成的信息(也可以由任何人从项目生成仪表板运行)，其中包括VS2k5"测试"解决方案。测试解决方案包含所有单元测试项目；每个主项目中的每个"单元"代码都需要一个单元测试项目。

运行自动构建时，它将构建主要解决方案，然后构建测试解决方案，最后运行测试解决方案生成的所有可执行文件(Perl脚本将其粘合在一起)。编译和测试执行的结果(EXIT _ SUCCESS，EXIT _ FAILURE)用于更新项目构建仪表板。

该EXIT_FAILURE技巧也可以应用于主项目的自定义构建步骤：如果单元测试的自定义构建步骤返回EXIT_FAILURE，则构建本身将失败。

我使用Boost测试框架。我倾向于将代码拆分为.lib文件，并且每个文件都有一个单独的控制台模式EXE测试项目。构建测试项目时，它将利用"构建后阶段"启动自身，从而运行测试。我们可以使每个测试项目都成为主应用程序的依赖项，以便每次构建时都首先运行所有测试，但这可能很耗时。相反，我倾向于根据需要手动运行测试项目，但是我的夜间自动构建系统会理所当然地运行所有测试项目(我将其编写为脚本，如果任何测试失败，则构建会失败并收到电子邮件通知)。

此处有更多详细信息。

我公司的一个项目正是这样做的。我们使用一个称为CXXTest(http://cxxtest.sourceforge.net/guide.html)的单元测试框架。我们真的很喜欢这个C ++框架，因为它只需要我们编写一个包含单元测试的头文件。 .CPP文件由脚本创建(提供了Python和Perl脚本)。

我们通过提供后期构建步骤与Visual Studio集成，该步骤可以构建单元测试(如果需要构建)，然后执行它们。输出(显示通过和失败的内容)显示在输出窗口中-无需离开IDE。

我们还可以使用托管的C ++，使用内置的单元测试框架在Visual Studio中编写单元测试。

• 我发现以下文件夹层次结构很有用。创建代码并测试作为ProjectFolder的子文件夹。创建2个解决方案代码\ Project.sln和tests \ Tests.sln。现在，对于每个创建的类库或者可执行文件，例如Customer.dll有一个相应的测试dll。因此，code \ Customers \ Customers.csproj将具有tests \ Customers \ TestCustomers.csproj，该引用了前者。
• 将CPPUnit集成到Visual Studio中将是在"项目属性"中选择正确的应用程序。"调试"设置。我认为该页面具有在IDE中进行单键测试执行和报告所需要的功能。

看看CUnitWin32. 也包括一个示例。

这是我的工作：

• 在主要解决方案中创建一个测试可执行项目，该项目仅使用来自单元，单元测试和测试框架的源代码。
• 使测试运行程序在测试成功运行时生成一个文本文件，以便Visual Studio可以跟踪依赖关系。
• 添加一个项目以启动测试运行器并生成测试文件。这意味着我们现在每个测试有两个项目。
• 使测试运行程序成为包含该单元的库的依赖项。

就我个人而言，我认为测试框架(Google测试，Boost测试，CppUnit等)并不那么重要。大多数功能在功能上是等效的。

我对生成的项目数量并不完全满意，但我认为这是Visual Studio GUI问题，从某种意义上说，将这些项目包含在其中对于调试等目的实际上很有用。

我尝试使用构建后步骤来运行测试，但是不幸的是，这意味着在第一个失败通过后构建并没有被打断。