2011-01-25 67 views
8

最近,我取得了一些C++代码的所有权。我将保留此代码,并在稍后添加新功能。 我知道很多人说现在的代码通常不值得添加单元测试,但是我仍然想添加一些至少部分覆盖代码的测试。特别是,我想添加测试,重现我固定的错误。如何确定现有的类是否可以进行单元测试?

一些类的构造有一些非常复杂的状态,这可能使单元测试更加困难。

我也愿意重构代码,使其更容易测试。

有没有什么好的文章可以帮助您找出更容易进行单元测试的指南?你有任何建议吗?

+2

“我知道很多人说,这是通常不值得补充单元测试,以现有的代码......” < - 你需要选择不同的人听。只是在说'。 – 2011-01-25 17:16:57

回答

6

尽管Martin Fowler关于重构的书是信息的宝库,为什么不看看“Working Effectively with Legacy Code”。另外,如果你打算处理那些存在大量全局变量或大量状态转换的类,那么我会进行大量的集成检查。分离出与重构代码相互作用的代码,确保按照接收顺序输入的所有期望输入继续产生相同的输出。这是非常重要的,因为它很容易“修复”可能在其他地方解决的细微错误。

做笔记了。如果你发现有另外一个函数/类期望并且正确处理的错误,你会想同时改变它们。除非你保存完整的记录,否则这很困难。

1

假设代码是为某个目的而编写的,单元测试将检查目的是否符合,即前提条件和后继条件是否适用于这些方法。

如果公共类方法是这样的,你可以从外部检查状态,它可以很容易地进行单元测试(黑盒测试)。如果类的状态是不可见的,或者您必须测试棘手的私有方法,那么您的测试类可能需要成为朋友(白盒测试)。

一类,是很难进行单元测试将是一个

  • 具有巨大的依赖关系,即紧密耦合
  • 有意识地在高容量或者多线程环境中工作。在那里你会使用系统测试而不是单元测试,实际的输出可能不是完全确定的。
0

几乎所有的东西都可以并应该进行单元测试。如果不是直接的,那么通过使用模拟类。

由于您决定重构您的类,请尝试使用BDD或TDD方法。

为了防止破坏现有功能,唯一的方法是进行良好的集成测试,但通常需要一段时间才能将它们全部用于复杂系统。

如果没有更多的细节你做什么,它不是那么容易给更多的实施细节。有些是:

  • 使用MVP或主持人首先为开发GUI
  • 使用设计模式,在适当情况下
  • 使用功能和成员指针,或观察者设计模式,打破依赖
+0

的解决方法往往在于部署大量的TLA – CashCow 2011-01-25 17:10:15

0

我认为,如果你不得不想出一些“测量”来测试一个类是否可测试,那么你已经被fscked了。你应该能够通过看看它来判断:你能编写一个独立的程序来链接到这个类,并确保它可以工作吗?

如果一个类是太庞大了,这样你不能肯定只是看它......机会是它可能是不可检验。不知道如何制作小而独特界面的人通常也不知道如何遵守任何其他原则。

在比赛的最后阶段,该办法找出如果一个类是可测试的就是尽量把它放在一个线束。如果你最终不得不把你的程序拉到一半,尝试重构。如果你发现你甚至不能在不重写整个程序的情况下执行最基本的重构,就要分析这样做的开销。

0

我们在IPL发表了一篇论文It's testing Jim, but not as we know it其中探讨的测试C++中的实际问题,并提出了一些技术来解决他们很可能给你的问题的使用。这些技术在Cantata ++中也得到了很好的支持 - 我们的C/C++单元和集成测试工具。

相关问题