向现有项目添加单元测试
我的问题与之前问过的问题非常相关 但我需要一些实用的建议。
我手中有《有效地处理遗留代码》，并且在我正在从事的项目中阅读这本书时，我正在使用书中的建议。 该项目是一个 C++ 应用程序，由几个库组成，但代码的主要部分被编译为单个可执行文件。 当我必须接触某些东西时，我正在使用 googletest 将单元测试添加到现有代码中。
我的问题是如何设置构建过程，以便构建单元测试，因为有两个不同的可执行文件需要共享代码，而我无法将代码从“测试中”应用程序提取到库。 现在，我已经为应用程序制定了构建过程，该过程将单元测试链接与主应用程序的构建过程生成的目标文件保持一致，但我真的不喜欢它。 有什么建议吗？
My question is quite relevant to something asked before but I need some practical advice.
I have "Working effectively with legacy code" in my hands and I 'm using advice from the book as I read it in the project I 'm working on. The project is a C++ application that consists of a few libraries but the major portion of the code is compiled to a single executable. I 'm using googletest for adding unit tests to existing code when I have to touch something.
My problem is how can I setup my build process so I can build my unit tests since there are two different executables that need to share code while I am not able to extract the code from my "under test" application to a library. Right now I have made my build process for the application that holds the unit tests link against the object files generated from the build process of the main application but I really dislike it. Are there any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
有效使用旧代码是有关如何开始测试旧代码的最佳资源。 确实没有任何短期解决方案不会导致事情变得更糟。
Working Effectively With Legacy Code is the best resource for how to start testing old code. There are really no short term solutions that won't result in things getting worse.
我将勾勒出一个您可以使用的 makefile 结构：
这大致就是我作为项目的唯一开发人员所做的事情
I'll sketch out a makefile structure you can use:
That is roughly what I do, as a sole developer on my project
如果您的测试应用程序仅链接需要测试的对象文件，那么您实际上已经将它们视为一个库，应该可以将这些对象文件分组到主应用程序和测试应用程序的单独库中。 如果你不能，那么我不认为你正在做的事情是一个太糟糕的选择。
如果您必须链接其他未测试的目标文件，那么这表明需要打破依赖关系，对此您有一本完美的书。
我们有类似的问题并使用类似于 Vlion 建议的系统
If your test app is only linking the object files it needs to test then you are effectively already treating them as a library, it should be possible to group those object files into a separate library for the main and the test app. If you can't then I don't see that what you are doing is too bad an alternative.
If you are having to link other object files not under test then that is a sign of dependencies that need to be broken, for which you have the perfect book.
We have similar problems and use a system like the one suggested by Vlion
我个人会像您一样继续这样做，或者考虑使用一个构建脚本来同时进行目标应用程序和单元测试（两个生成的二进制文件来自同一代码库）。 是的，它闻起来有腥味，但非常实用。
向您致敬并祝您测试顺利。
I personally would continue doing as you are doing or consider having a build script that makes the target application and the unit tests at the same time (two resulting binaries off the same codebase). Yes it smells fishy but it is very practical.
Kudos to you and good luck with your testing.
我更喜欢每个测试一个测试可执行文件。 这可以实现链接时接缝，并且还有助于允许 TDD，因为您可以在一个单元上工作，而不必担心其余代码。
我使库依赖于所有测试。 希望这意味着您的测试仅在代码实际更改时运行。
如果确实失败，测试将在正确的位置中断构建过程。
I prefer one test executable per test. This enables link-time seams and also helps allow TDD as you can work on one unit and not worry about the rest of your code.
I make the libraries depend on all of the tests. Hopefully this means your tests are only run when the code actually changes.
If you do get a failure the tests will interrupt the build process at the right place.