C++单元测试遗留代码:如何处理#include？

我刚刚开始使用#include指令为具有大型物理依赖性的遗留代码模块编写单元测试.我一直在处理它们的一些感觉过于繁琐的方法(提供空标题来打破长#include依赖列表,并使用#define来防止编译类)并且正在寻找一些更好的策略来处理这些问题.

我经常遇到几乎每个头文件都复制一个空白版本的问题,以便将我正在测试的类分开,然后为需要的对象编写大量的存根/模拟/伪代码取而代之,因为他们现在尚未定义.

谁知道一些更好的做法？

回应中的萧条是压倒性的...但不要害怕,我们已经得到了圣书来驱除遗留C++代码的恶魔.如果你与传统的C++代码进行超过一周的争夺,那么请认真购买这本书.

转到第127页:可怕的情况包括依赖性.(现在我甚至不在迈克尔·费瑟斯的数英里之内,但在这里,我可以管理答案......

问题:在C++中,如果classA需要了解ClassB,则Class B的声明直接提升/文本包含在ClassA的源文件中.而且由于我们的程序员喜欢将它带到错误的极端,因此文件可以递归地包含数以万计的其他文件.构建需要数年......但是至少它构建了......我们可以等待.

现在说'在测试工具下实例化ClassA很困难'是轻描淡写的.(引用MF的例子 - 调度员是我们的海报问题孩子与deps嘉豪.)

#include "TestHarness.h"
#include "Scheduler.h"
TEST(create, Scheduler)     // your fave C++ test framework macro
{
  Scheduler scheduler("fred");
}

这将带来一系列构建错误的包含龙.
打击#1 Patience-n-Persistence:每次包含一个,并决定我们是否真的需要这种依赖.假设SchedulerDisplay是其中之一,其displayEntry方法在Scheduler的ctor中调用.
打击#2假它直到你做它(谢谢RonJ):

#include "TestHarness.h"
#include "Scheduler.h"
void SchedulerDisplay::displayEntry(const string& entryDescription) {}
TEST(create, Scheduler)
{
  Scheduler scheduler("fred");
}

pop流行依赖,其所有传递都包括在内.您还可以通过将Fake方法封装在Fakes.h文件中来重用Fake方法,以包含在测试文件中.
打击#3练习:可能并不总是这么简单......但是你明白了.在最初的几次决斗之后,打破deps的过程将变得容易机械化

注意事项(我提到有警告吗？:)

我们需要在此文件中为测试用例单独构建; 我们在程序中只能有SchedulerDisplay :: displayEntry方法的1个定义.因此,为调度程序测试创建一个单独的程序.

我们没有打破程序中的任何依赖关系,因此我们不会使代码更清晰.

只要我们需要测试,你需要保持这些假货.

你的美学感可能会被冒犯一段时间......只要咬住你的嘴唇并"忍受我们的美好明天"

将此技术用于具有严重依赖性问题的非常庞大的类.不要经常使用或轻轻使用 .. 以此作为深层重构的起点.随着时间的推移,当您提取更多类(使用他们自己的测试)时,可以在谷仓后面执行此测试程序.

更多..请阅读本书.无价.战斗兄弟!