如何组织C++测试应用程序和相关文件？

我正在研究一个C++库（其他东西）有读取配置文件的功能;我想为此添加测试。到目前为止，这导致我创建了大量有效和无效的配置文件，每个配置文件只有几行可以测试一个特定的功能。但它现在变得非常笨拙，因为有这么多的文件，还有很多小的C++测试应用程序。不知何故，这对我来说似乎是错误的:-)所以你有什么提示如何组织所有这些测试，测试应用程序和测试数据？如何组织C++测试应用程序和相关文件？

注意：库的公共API本身不易测试（它需要配置文件作为参数）。实际阅读和解释配置值的多汁，容易出错的方法是私有的，所以我没有看到直接测试它们的方法？

所以：你会坚持测试真实的文件;如果是这样，你将如何组织所有这些文件和应用程序，以便它们仍然可以维护？

来源

2008-10-09 oliver

也许库可以接受某种流输入，所以你可以传入类似字符串的对象并避免所有的输入文件？或者根据配置类型，您可以提供“get/setAttribute（）”函数来直接，公开，调整参数。如果这不是一个真正的设计目标，那么没关系。数据驱动的单元测试在一些地方被忽视，但它肯定比没有好！我可能会制定出这样的代码：

project/ 
      src/ 
      tests/ 
       test1/ 
         input/ 
       test2 
         input/

在每testN目录你会关联到输入目录中的配置文件的cpp文件。

然后，假设您正在使用的xUnit风格的测试库（cppunit，googletest，unittest++，或其他），你可以添加各种的testXXX（）函数来一个类来测试的功能相关联基团。这样，您可以通过将至少一些测试分组在一起来削减部分小程序问题。

唯一的问题是，如果库期望配置文件被称为特定的东西，或在一个特定的地方。这不应该是这种情况，但是如果它必须通过将测试文件复制到预期位置来解决。

不要担心大量的测试会让你的项目混乱，如果他们藏在测试目录中，那么他们就不会打扰任何人。

来源

2008-10-09 10:38:07 richq

在一些测试中，我已经使用测试代码来编写配置文件，然后在测试使用该文件后将其删除。它在一定程度上填充了代码，我不知道这是否是好的做法，但它工作。如果您碰巧使用boost，那么它的文件系统模块对创建目录，导航目录和删除文件很有用。

来源

2008-10-09 10:43:23

我同意@Richard Quirk所说的，也可能希望让测试套件类成为您正在测试的类的朋友并测试其私有函数。

来源

2008-10-09 10:45:16 Lev

第1部分：

正如理查德的建议，我想看看在CPPUnit测试框架。这将在一定程度上推动测试框架的位置。

根据Richard的示例，您的测试可以位于高级并行目录中，也可以位于与要测试的区域平行的测试子目录或测试目录中。

无论哪种方式，请在项目的目录结构中保持一致！ 尤其是在测试包含在单个高级目录中的情况下。

还有什么比不得不维持在如位置的源代码中的心理映射：

/project/src/component_a/piece_2/this_bit

且位于测试（S）的地方，如：

/project/test/the_first_components/connection_tests/test_a

而且我曾参与过有人这样做的项目！

什么是浪费wetware周期！ 8-O谈论违反亚历山大的质量而不命名的概念。

更好的是让您的测试始终位于w.r.t.下测试的源代码的位置：

/project/test/component_a/piece_2/this_bit/test_a

第2部分

作为用于API配置文件，使基准配置的本地副本在每个局部测试区域作为测试ENV的一部分。在执行测试之前运行的设置。不要在您的测试树中添加配置（或数据）的副本。

HTH。

欢呼声，

罗布

BTW非常高兴见到你问这个现在设置东西的时候！

来源

2008-10-09 11:11:27

对于这样的事情，我总是有一个小实用程序类，它会将配置加载到内存缓冲区中，并从那里获取到实际配置类中。这意味着真正的来源并不重要 - 它可能是一个文件或数据库。对于单元测试，它在std :: string中被硬编码，然后传递给类进行测试。您可以轻松模拟currup！pte3d数据以测试故障路径。我想用UnitTest++。我将测试作为src树的一部分。所以：

solution/project1/src <-- source code 
solution/project1/src/tests <-- unit test code 
solution/project2/src <-- source code 
solution/project2/src/tests <-- unit test code

来源

2008-10-09 11:20:16

假设你有在图书馆的设计控制，我希望你会能够重构，这样你分开实际文件从将其解释为一个配置文件读取的担忧：

类的FileReader读取文件，并产生一个输入流，
类ConfigFileInterpreter验证/解释等的输入流的内容

现在要测试FileReader，您只需要非常少量的实际文件（空白，二进制，纯文本等），而对于ConfigFileInterpreter，您将使用FileReader类的存根，该文件返回输入流以读取。现在，您可以将所有各种配置情况准备为字符串，而不必阅读太多文件。

来源

2008-10-09 11:46:55

您不会发现比CppUnit更差的单元测试框架。说真的，任何推荐CppUnit的人都没有真正看过任何竞争的框架。

所以是的，去一个单位测试franework，但不要使用CppUnit。

来源

2009-04-12 20:31:22

如何组织C++测试应用程序和相关文件？

回答

相关问题