TL; DR
编写好的，有用的测试很困难，并且在C ++中代价很高。您是否有经验的开发人员可以就什么以及何时进行测试分享您的理论依据？
很长的故事
我曾经做过测试驱动的开发，实际上是整个团队，但对我们来说效果不佳。我们有很多测试，但是它们似乎从来没有覆盖我们有实际错误和回归的情况-通常是在单元交互时发生的，而不是因为它们孤立的行为而发生。
这通常很难在单元级别进行测试，以至于我们停止了TDD测试（组件确实可以加快开发速度），而花了更多时间增加集成测试的覆盖范围。尽管小型单元测试从未捕获任何实际的错误，并且基本上只是维护开销，但集成测试确实值得付出努力。
现在，我继承了一个新项目，并且想知道如何进行测试。它是本机C ++ / OpenGL应用程序，因此集成测试并不是真正的选择。但是C ++中的单元测试比Java中的要难一些（您必须显式地制作东西virtual），并且该程序不是很面向对象的，所以我无法模拟/存根一些东西。
我不想为了编写测试而仅仅为了编写一些测试而拆开并OO化整个过程。所以我问你：我应该为测试写什么？例如：
- 我希望经常更改的函数/类？
- 难以手动测试的函数/类？
- 已经易于测试的功能/类？
我开始研究一些受人尊敬的C ++代码库，以了解它们如何进行测试。现在，我正在研究Chromium源代码，但发现很难从代码中提取其测试依据。如果有人有一个很好的例子或关于C ++用户（委员会，书籍作者，Google，Facebook，Microsoft等人的看法）如何发表文章的帖子，那将特别有帮助。
更新资料
自编写此书以来，我一直在这个网站和网络上进行搜索。找到了一些好东西：
- 什么时候不进行单元测试？
- /programming/109432/what-not-to-test-when-it-comes-to-unit-testing
- http://junit.sourceforge.net/doc/faq/faq.htm#best
可悲的是，所有这些都是以Java / C＃为中心的。用Java / C＃编写大量测试不是一个大问题，因此收益通常超过了成本。
但是正如我上面所写，在C ++中要困难得多。尤其是如果您的代码库不是那么OO，那么您就必须认真弄乱事情，以获得良好的单元测试覆盖率。例如：我继承的应用程序具有一个Graphics名称空间，该名称空间是OpenGL之上的薄层。为了测试任何实体（它们都直接使用其功能），我必须将其变成一个接口和一个类，并将其注入所有实体中。那只是一个例子。
因此，在回答这个问题时，请记住，我必须在编写测试方面投入大量资金。