C++ 代码整洁之道:C++17 可持续软件开发模式实践 (17):构建安全体系 2.5.3

阅读数:7 2019 年 12 月 4 日 18:48

C++代码整洁之道:C++17可持续软件开发模式实践(17):构建安全体系 2.5.3

(单元测试的独立性)

内容简介
本书致力于讲述 C++ 整洁代码之道!如果你想让自己写的代码更加整洁,那么这本书适合你阅读。本书需要熟悉 C++ 语言的基本概念,才能有效的掌握其中的内容。如果你只是想从 C++ 开发开始,并且没有 C++ 语言的基础知识,你应该首先选择一个好的 C++ 入门的练习项目。此外,本书也不包含任何深奥的技巧和杂乱的知识点。我知道 C++ 有很多令人兴奋的技巧,但这些通常不是整洁代码的精神,也不是现代 C++ 的代码风格。除此之外,这本书为了帮助 C++ 程序员提高技能水平,并举例说明如何编写易于理解的、灵活的、可维护的和高效的 C++ 代码。即使你是一个经验丰富的 C++ 开发人员,这本书中也有一些值得学习的地方,我认为这些值得学习的地方能够促进你的工作。书中所提出的原则和实践可以应用于新的软件系统,有时被称为“绿地项目”,以及具有悠久历史的遗留系统,通常被称为“棕地项目”。

每个单元测试和其他的单元测试都必须是独立的。如果单元测试之间是以特定的顺序执行的,那么这将是致命的,因为一个单元测试的执行依赖于前一个单元测试的影响,例如,改变了类的状态,改变了上下文环境等。永远不要编写“一个单元测试的输出是另一个单元测试的输入”的单元测试。当离开一个单元测试的时候,不应该改变测试单元的状态1,这是后续单元测试执行的先决条件。

1 单元测试之间是独立的,离开任何一个单元测试后,单元测试的上下文环境应当一致。——译者注

主要的问题可能是由全局状态引起的,例如,在单元测试中使用单例或使用了静态的成员。单例不仅增加了单元测试之间的耦合度,还经常会保持一个全局的状态,单元测试之间因为全局状态而变得相互依赖。例如,如果一个全局状态是某个单元测试成功执行的先决条件,当前面的单元测试成功执行并修改了这个全局状态时,那么接下来的单元测试就会执行失败。

尤其是在遗留系统中,经常杂乱无章地使用单例模式,这就引出了一个问题:如何才能摆脱这些杂乱无章的对单例的依赖关系,让我们的代码更易于测试呢?这是在第 6 章的依赖注入部分讨论的一个重要问题。

处理遗留系统
如果你在所谓的遗留系统中添加单元测试时遇到许多困难,我强烈推荐 Michael C 写的《Working Effectively with Legacy Code》[Feathers07]。这本书包含了许多策略,用于处理大型的、未经测试的遗留代码,这本书还包括了 24 种依赖中断技术。当然,这些策略和技术超出了本书的范围。

C++代码整洁之道:C++17可持续软件开发模式实践(17):构建安全体系 2.5.3

购书地址 https://item.jd.com/12599914.html?dist=jd

评论

发布