单元测试。文件结构答案

【问题标题】：Unit testing. File structure单元测试。文件结构
【发布时间】：2009-11-09 15:44:39
【问题描述】：

我有一个包含 10-15 个应用程序的 C++ 遗留代码库，它们都共享多个组件。

在为共享组件和应用程序本身设置单元测试时，我想知道是否有为此接受/通用的文件结构。

因为我的单元测试有几个基类以简化项目/客户特定的测试设置，所以有很多文件对所有测试都是通用的。

对我来说，在这里创建一个包含所有与测试相关的文件、模拟文件等的新目录似乎很自然 - 将它们全部集中起来，并将与测试相关的定义排除在主 make 文件之外。

另一方面，我发现将测试文件与他们测试的代码文件放在一起是一种常见的做法。

有更多/更少被接受的方式吗？

【问题讨论】：

标签： c++ unit-testing

【解决方案1】：

眼不见，心不烦；如果您将测试文件与代码文件放在一起，开发人员可能会更清楚地知道，当他们更新代码文件时，他们也应该更新测试。

【讨论】：

【解决方案2】：

如您所述，定位单元测试文件的常用方法有两种：在它们正在测试的实现代码附近，以及在单独的文件层次结构中。选择取决于您的组织中的常见做法和个人品味。

关于常用测试代码的位置，只要组织你的测试代码，你就会组织实现代码。

在您的特定情况下，如果某些测试基础架构对多个独立组件是通用的，那么创建一个新组件（例如，称为“测试”）以供其他组件进行测试是一个好主意，而不是在现有组件之间添加依赖关系。

【讨论】：

【解决方案3】：

我通常将此类代码组织在一个文件结构中，看起来（在简单的情况下）如下所示：

apps
    app1
        app1module1
        app2module2
        app1tests
    app2
        app2module1
        app2tests
components
    comp1
        comp1module1
        comp1module2
        comp1tests
common_test_stuff

没有一种正确的方法可以做到这一点，但这似乎是一种常见的做法，它将生产代码和测试代码分开，并尝试删除看不见的、心烦意乱的 问题（zac 提到）。

【讨论】：

app2module2 应该是 app1module2。

【解决方案4】：

保持测试代码接近产品代码，并安排您的 Makefile（或您正在使用的任何文件），以便测试与测试同时编译，使其可见，特别是如果不是团队中的每个人正在编写测试。

【讨论】：