第十次读书笔记 软件工程：方法与实践

单元测试

咱们在开发的过程当中应该实时的对新产生的代码进行测试，一是为了及时发现问题及时更改，避免往后代码复杂庞大，debug工做难度会指数级上升，这样及时测试，缩小了bug范围，能快速找到问题关键，避免没必要要的时间浪费；不断的发现问题，多是是本身编写代码前逻辑关系的错误，这种致命的错误越早发现，越早改正，越早走上正轨，还能帮助本身更好的理解总体的框架内容，逻辑结构。

单元测试应该由软件开发人员进行，而不是专门的测试团队。本身开发的代码，本身内心清楚内部的处理是怎么进行的，换另外一我的测试会大大下降测试效率。更加广义的测试不只仅是测试漏洞的所在，还能够是测试代码的运行效果，而且进行一些修改、优化、更正，这些显然不是另外一个专门的测试人员能够轻松作到了。那么，如上所述能够清晰的看到，代码一经编写，就要及时测试，因此单元测试与代码的编写是一体的，能够看做是软件构架的一部分。

单元测试应尽量的采起自动化的方式。单元测试应该和代码修改同步，频繁执行。以开发人员手工测试的时间成本和精力成本是巨大的。那么自动化的测试能够大大减轻开发人员的负担，还能够增长测试的频率。可是这一步我尚未学到什么方法能够作到这一点，除了用一些集成功能强大的IDE能够自动检查一些基础的bug其余都仍是只能开本身手动检查。

所谓单元、单元，确定是要将代码隔离分开进行测试。那么怎么隔离就是一个首先要想到的问题。回忆结对编程的过程，就是要在编写代码的时候有很清晰的逻辑层次，调用层次，将整个代码框架方块化模块化，那么对于每个模块就是一个个较为独立的单元，优先编写下层代码，测试下层单元，而后再写上层的代码，上层代码不免会必须调用下层代码，但这时下层代码已经被检查测试过不会是bug的发生点，贯彻了单元测试的优点（快速找到问题所在）与意义（实时检查），如若下层代码未编写完成，那么先编写的上层代码就没办法很好地检查测试，堆积问题，这样就违背了单元测试的初衷。

自动化单元测试框架

自动化单元测试框架通常都须要提供的功能有：（1）方便地编写测试用例，并清晰地声明指望的测试结果；（2）运行测试用例，检查测试用例的运行结果并产生报告；（3）对测试用按照必定的规则进行组织。测试广泛所用的框架有：JUnit、NUnit、cppUTest。使用了统一的某几个框架可使全部人编写测试代码时统一风格，保持一致性；同时确定能够提升测试的开发效率。

测试单元代码也是代码，要简单，全面地检查到各类状况。测试代码也要遵循编写代码的一些要求：可理解性，可维护性等等。每个测试代码的编写都应该遵循创建——执行——验证——拆卸四个步骤。

创建阶段：所谓创建阶段是指测试代码创建被测试代码的前置条件，使得被测试单元为测试作好准备；

执行阶段：测试代码调用被测单元接口；

验证阶段：测试代码经过断言肯定是否得到预期的结果，从而判断被测试代码的正确性；

拆卸阶段：测试代码，将被测目标及环境恢复到测试前的初始状态，以免影响后续的测试。