测试开发

当前位置:首页 > 测试开发

测试驱动的面向对象软件开发(第二十章)

第四部分 可持续的测试驱动开发

这一部分讨论我们在测试代码中追求的品质,这些品质让开发变得“适合长期居留"。通过让测试具有表现力,我们希望确保它们能尽力做好工作,这样在阅读代码或测试执行失败时,就知道什么地方重要。同时,我们也确保这些测试不会成为维护的负担。像对待产品代码一样,我们需要对测试代码给予同样的关注,虽然编码的风格可能不同。难以测试可能意味着需要改变测试代码,但这常常也意味着设计有问题,我们应该改变产品代码。

我们将这些建议安排在独立的几章中,但这主要是因为本书需要一个线性的结构。在实践中,这些品质是相互关联和支持的。测试驱动开发将测试、规格说明和设计结合在一个整体式的活动中。


第20章 聆听测试

通过观察,您可以看到许多东西。

——Yogi Berra

20.1简介

有时候我们发现,很难为想添加的某项功能写一个测试。根据经验,这通常意味着设计需要改进一也许类与环境的耦合度太高,也许类的职责不清晰。发生这种情况时,我们首先检查是否有机会改进代码,然后才是绕过设计让测试变得更复杂,或使用更复杂的工具。我们发现,让对象容易测试的那些品质,也让代码更容易响应变化。

这种技术让测试来驱动我们的设计(这就是为什么称之为测试驱动开发)。TDD是有关测试代码的、验证代码的功能和性能等外部品质。TDD 也是有关代码内部品质的反馈:类的耦合和内聚、显式或隐式的依赖关系、有效的信息隐藏一这些品质与代码的可维护性有关。

通过实践,测试中的粗糙之处变得更为敏感,所以可以利用测试作为设计的快速反馈。现在,当发现某项功能难以测试时,我们不会只问自己如何测试它,而是会问为什么它难以测试。

在这一章中,我们来看看曾遇到过的某些常见的“测试坏味道",并讨论它们对代码的设计可能意味着什么。有两大类的测试坏味道需要考虑。一种是测试本身写得不好它可能不清晰或比较脆弱。Meszaros 在他的著作[ Meszaros07]的"Test Smell”一章中介绍了几种这类情况。本章要讨论的是另一大类,即测试提示出目标代码是有问题的。Meszaros 有一种模式讲的是这种情况,称为“ 难以测试的代码"。这里选取了一些看到过的常见情况,这些情况与我们采用的TDD方式有关系。

20.2我需要模拟一个不能替换的对象

20.2.1单例是依赖关系

关于减少代码的复杂性,有一种解释是让通用的对象可以通过一种全局结构来访问,通常这种对象实现为一个单例( singleton)。所有需要访问一项功能的代码都可以用单例的全局名称来访问它,而不是通过参数来接收它。下面是一个常见的例子:

Date now=now Date();

在这段代码背后,构造方法调用了单例System, 利用System. curentTimMillis ()将新的实例设置为当前的时间。这是一种方便的技术,但它是有代价的。假定我们想写下面的测试:


文章评论

表情

共 0 条评论,查看全部
  • 这篇文章还没有收到评论,赶紧来抢沙发吧~