如何将单元测试引入到一个大型的遗留(C/C + +)代码库中？

首先要使它更加模块化要容易得多。您不能真正地对具有很多依赖项的内容进行单元测试。何时进行重构是一个棘手的计算。你真的必须权衡成本和风险与收益。这些代码是否可以被广泛地重用？或者这个代码真的不会改变。如果您打算继续使用它，那么可能需要重构。

但是听起来，您需要重构。您需要从分解最简单的实用程序开始，并在它们的基础上进行构建。你的 C 模块可以做很多事情。例如，也许有些代码总是以某种方式格式化字符串。也许这可以被提出来作为一个独立的实用模块。你已经有了新的字符串格式化模块，你已经使代码更具可读性。这已经是进步了。你声称自己陷入了两难的境地。你真的不是。通过移动代码，可以使代码更具可读性和可维护性。

现在您可以为这个断开的模块创建一个单元测试。你可以有几种方法。你可以创建一个单独的应用程序，它只包含你的代码，并在你的电脑上的一个主例程中运行一系列的用例，或者定义一个名为“ UnitTest”的静态函数，它将执行所有的测试用例，如果它们通过，返回“1”。这个可以在目标上运行。

也许您不能100% 使用这种方法，但是这只是一个开始，它可能使您看到其他可以轻松分解为可测试实用程序的东西。

要考虑的一种方法是首先放置一个系统范围的模拟框架，您可以使用这个框架来开发集成测试。从集成测试开始似乎有违直觉，但是在您描述的环境中进行真正的单元测试的问题是相当可怕的。可能不仅仅是在软件中模拟整个运行时..。

这种方法将简单地绕过您列出的问题——尽管它会给您带来许多不同的问题。但是在实践中，我发现使用一个健壮的集成测试框架，您可以开发在单元级别执行功能的测试，尽管不需要单元隔离。

PS: 考虑编写一个命令驱动的模拟框架，可以在 Python 或 Tcl 上构建。这将使您可以非常容易地编写测试脚本..。

你好,

我会先看看任何明显的地方，例如在头文件中使用 dec。

然后开始查看代码是如何布局的。这符合逻辑吗？也许开始把大文件分解成小文件。

也许可以借用 Jon Lakos 的优秀著作《大规模 C + + 软件设计》(Large-Scale C + + Software Design，经过消毒的亚马逊链接) ，从中得到一些关于如何布局的想法。

一旦你开始对代码本身更有信心，比如代码布局和文件布局一样，并且清除了一些不好的味道，比如在头文件中使用 dec，那么你就可以开始挑选一些可以用来开始编写单元测试的功能。

选择一个好的平台，我喜欢 CUnit 和 CPPUnit，并从那里开始。

不过这将是一段漫长而缓慢的旅程。

高温

干杯,

我们还没有找到任何东西来缓解“毛球”的过渡 没有单元测试的代码”到“可单元测试的代码”。

多么悲哀——没有奇迹般的解决方案——只是许多艰苦的工作纠正了多年来积累的 技术债务。

没有简单的过渡，你有一个大的，复杂的，严重的问题。

你只能用很小的步骤来解决它。

1. 选择一段绝对重要的离散代码。(不要轻咬垃圾食品的边缘。)选择一个重要的部件，然后——不知怎么地——可以从其他部件中雕刻出来。虽然单个函数是理想的，但它可能是一个复杂的函数集群，也可能是一个完整的函数文件。对于您的可测试组件来说，从不完美的事物开始是可以的。

2. 弄清楚它的作用。弄清楚它的接口应该是什么。要做到这一点，您可能需要进行一些初始重构，以使您的目标部分实际上是离散的。

3. 编写一个“整体”集成测试，该测试目前或多或少地测试您的离散代码片段。在你尝试改变任何重要的事情之前，让这个过去。

4. 将代码重构成整洁的、可测试的单元，使其比当前的毛球更有意义。你需要在整体集成测试中保持一些向下兼容。

5. 为新单元编写单元测试。

6. 一旦这一切都通过了，废除旧的 API 并修复因更改而破坏的内容。如果有必要，重新进行原始的集成测试; 它测试旧的 API，您需要测试新的 API。

重复。

迈克尔 · 费瑟斯在这上面写了圣经 有效使用遗留代码

我在遗留代码和引入测试方面的一点经验就是创建“ 角色塑造测试”。您开始创建具有已知输入的测试，然后获得输出。这些测试对于那些您不知道它们实际上是做什么的方法/类很有用，但是您知道它们是有效的。

然而，有时几乎不可能创建单元测试(甚至是角色塑造测试)。在这种情况下，我通过验收测试(本例中为 健身)来解决问题。

您创建了测试一个特性并检查其适应性所需的所有类。它类似于“角色塑造测试”，但它更高一级。

我在 Green field 项目中工作过，使用了完整的单元测试代码库和大型 C + + 应用程序，这些应用程序已经发展了很多年，并且有很多不同的开发人员在使用它们。

老实说，我不会费心尝试将遗留代码基础设置为单元测试和测试优先开发可以增加很多价值的状态。

一旦遗留代码基达到了一定的规模和复杂度，单元测试覆盖率为您提供了很多好处，这个任务就相当于完全重写。

主要问题是，一旦开始重构可测试性，就会开始引入 bug。只有当您获得高的测试覆盖率时，您才能期望发现并修复所有这些新的 bug。

这意味着您要么非常缓慢而小心地前进，要么直到多年以后才能从良好的单元测试代码库中获得好处。(可能自从合并等事情发生后就再也没有了。)与此同时，您可能正在引入一些对软件的最终用户没有明显价值的新 bug。

或者您进行得很快，但是代码基础不稳定，直到所有代码都达到了较高的测试覆盖率。(所以最终会有两个分支，一个在生产环境中，一个在单元测试版本中。)

当然，对于一些项目来说，重写可能只需要几个星期的时间，而且肯定是值得的。

正如乔治所说，有效地使用遗留代码就是这类事情的圣经。

然而，您团队中的其他人能够接受的唯一方法是，他们能够亲眼看到保持测试工作对他们的好处。

要实现这一点，您需要一个尽可能易于使用的测试框架。为其他开发人员制定计划，以您的测试为例编写他们自己的测试。如果他们没有单元测试经验，不要指望他们花时间学习一个框架，他们可能会认为编写单元测试会减慢他们的开发，所以不知道框架是跳过测试的借口。

花一些时间在使用巡航控制，半自动驾驶，快速行驶等持续集成上。如果您的代码每晚都自动编译并运行测试，那么开发人员将开始看到单元测试在 qa 之前捕获 bug 的好处。

鼓励共享代码所有权。如果一个开发人员更改了他们的代码并破坏了其他人的测试，他们不应该期望那个人修复他们的测试，他们应该调查为什么测试不能工作并自己修复它。根据我的经验，这是最难做到的事情之一。

大多数开发人员编写某种形式的单元测试，有时是一小段他们没有签入或集成构建的一次性代码。轻松地将这些集成到构建中，开发人员就会开始买账。

我的方法是添加针对新代码的测试，当代码被修改时，有时您无法添加您想要的那么多或者那么详细的测试，而不需要解耦太多的现有代码，因此在实际应用中会出现错误。

我唯一坚持单元测试的地方是在平台特定的代码上。如果将 # ifdefs 替换为平台特定的高级函数/类，则必须使用相同的测试在所有平台上测试这些函数/类。这节省了添加新平台的大量时间。

我们使用 ost: : test 来构建我们的测试，简单的自注册函数使编写测试变得容易。

这些都包装在 CTest (CMake 的一部分)中，它一次运行一组单元测试可执行文件并生成一个简单的报告。

我们的夜间构建通过 ant 和 luntbuild (ant glues c + + ，. net 和 java 构建)实现自动化

很快，我希望向构建中添加自动部署和功能测试。

我认为，基本上你有两个独立的问题:

1. 用于重构的大代码库
2. 团队合作

模块化、重构、插入单元测试等等都是一项艰巨的任务，我怀疑任何工具都无法承担这项工作的更大部分。这是一种罕见的技能。有些程序员可以做得很好。大多数人都不喜欢。

与一个团队一起完成这样的任务是乏味的。我强烈怀疑“强迫”开发人员的做法是否会奏效。Iains 的想法很好，但是我会考虑找到一两个能够并且想要“清理”源代码的程序员: 重构，Modualrize，引入单元测试等等。让这些人做这项工作，其他人引入新的错误，嗯的功能。只有从事 喜欢那种工作的人才能胜任那项工作。

使使用测试变得容易