最近，我获得了一些c ++代码的所有权。我将维护此代码，并在以后添加新功能。 我知道很多人说通常不值得在现有代码中添加单元测试，但我还是想添加一些至少部分覆盖代码的测试。特别是，我想添加重现我修复的错误的测试。
某些类的构造具有一些非常复杂的状态，这使得单元测试变得更加困难。
我也愿意重构代码，以便更容易测试。
您是否有任何关于有助于识别更容易进行单元测试的类的指南的好文章？你有自己的建议吗？
答案 0 :(得分：6)
虽然Martin Fowler关于重构的书是一个宝库，但为什么不看看“Working Effectively with Legacy Code。”
另外，如果你要处理那些有大量全局变量或大量状态转换的类，我会进行大量的集成检查。分离出与您正在重构的代码交互的代码，以确保按照接收顺序的所有预期输入继续产生相同的输出。这很关键，因为它很容易“修复”可能已在其他地方解决过的微妙错误。
也做笔记。如果你确实发现另一个函数/类需要并且正确处理的错误，你会想要同时更改它们。除非你保持完整的记录，否则这很困难。
答案 1 :(得分：1)
据推测，代码是出于某种目的编写的，单元测试将检查是否符合目的，即方法的前置条件和后置条件。
如果公共类方法可以从外部检查状态，则可以很容易地进行单元测试（黑盒测试）。如果类状态是不可见的，或者你必须测试棘手的私有方法，那么你的测试类可能需要成为朋友（白盒测试）。
难以进行单元测试的类将是
答案 2 :(得分：1)
我写了很多关于单元测试，非平凡的C ++代码的博客文章：http://www.lenholgate.com/blog/2004/05/practical-testing.html
我还写了很多关于在现有代码中添加测试的内容：http://www.lenholgate.com/blog/testing/
答案 3 :(得分：0)
几乎所有东西都可以而且应该进行单元测试。如果不是直接的，则使用模拟类。
由于您决定重构类，请尝试使用BDD或TDD方法。
为了防止破坏现有功能，唯一的方法是进行良好的集成测试，但通常需要时间来为复杂系统执行所有功能。
如果没有更多关于您的工作的详细信息，提供更多实施细节并不容易。有些是：
答案 4 :(得分：0)
我认为，如果你不得不提出一些“措施”来测试一个类是否可测试，那么你已经被攻击了。你应该能够通过观察它来判断：你能写一个独立的程序，单独链接到这个类并确保它有效吗？
如果一个课程太大，以至于你不能确定只是通过观察它......可能是不可测试的。那些不知道如何制作小而独特的界面的人通常也不知道如何遵守任何其他原则。
最后，找出一个类是否可测试的方法是尝试将其放入线束中。如果您最终需要将程序的一半拉出来，请尝试重构。如果您发现在不必重写整个程序的情况下甚至无法执行最基本的重构，请分析这样做的费用。
答案 5 :(得分：0)
我们在IPL上发表了一篇论文It's testing Jim, but not as we know it，该论文探讨了测试C ++的实际问题，并提出了一些解决这些问题的技巧，这些技术在您提出问题时很有用。 Cantata ++ - 我们的C / C ++单元和集成测试工具也很好地支持这些技术。