事实上,您是否曾将旧单元测试添加到遗留代码中？代码有多复杂,存根和模拟一切有多难？最终结果值得吗？
我们有一个用C语言编写的大型多平台应用程序(只有少量但不断增长的C++)多年来,它已经发展了许多你期望在大型C/C++应用程序中使用的功能:
#ifdef 地狱由于此代码是针对嵌入式设备的,因此在实际目标上运行它需要大量开销.因此,我们希望在本地系统上以快速周期进行更多的开发和测试.但我们希望避免"在您的系统上复制/粘贴到.c文件,修复错误,复制/粘贴"的经典策略.如果开发人员要麻烦这样做,我们希望以后能够重新创建相同的测试,并以自动方式运行.
这是我们的问题:为了使代码重构更加模块化,我们需要它更易于测试.但是为了引入自动化单元测试,我们需要它更加模块化.
一个问题是,由于我们的文件太大,我们可能在文件中有一个函数调用同一个文件中的函数,我们需要将它们存根以进行良好的单元测试.看起来这不是一个问题,因为我们的代码变得更加模块化,但这还有很长的路要走.
我们想到的一件事是用注释标记"已知可测试"的源代码.然后我们可以为可测试代码编写脚本扫描源文件,将其编译在单独的文件中,并将其与单元测试链接.我们可以在修复缺陷和添加更多功能时慢慢引入单元测试.
但是,有人担心维护这个方案(以及所有必需的存根函数)将变得太麻烦,开发人员将停止维护单元测试.所以另一种方法是使用一个工具,为所有代码自动生成存根,并将文件链接到该工具.(我们发现这样做的唯一工具是昂贵的商业产品)但是这种方法似乎要求我们所有的代码在我们开始之前都要更加模块化,因为只有外部调用可以被删除.
就个人而言,我宁愿让开发人员考虑他们的外部依赖关系并智能地编写他们自己的存根.但是,对于一个可怕的过度生长的10000行文件来说,这可能是压倒性的.可能很难说服开发人员他们需要为所有外部依赖项维护存根,但这是正确的方法吗？(我听到的另一个论点是子系统的维护者应该维护子系统的存根.但是我想知道"强迫"开发人员编写自己的存根会导致更好的单元测试吗？)
的#ifdefs,当然,再添全尺寸的问题.
我们已经研究了几个基于C/C++的单元测试框架,并且有很多选项看起来很好.但是我们还没有找到任何方法来缓解从"没有单元测试的代码毛球"到"单元可测试代码"的过渡.
所以这是我对其他任何经历过这个问题的人的问题:
注意,我们的构建环境基于Linux/UNIX,因此我们不能使用任何仅限Windows的工具.