第二十四章 单元测试和提测质量哪个更重要？
在等待开发提测的日子里，听到开发最多的抱怨就是：时间太紧了，没时间做单元测试？在项目进度会议上，经常就听到开发负责人抱怨，你们既要我达到XX%的单元测试覆盖率，又要我保证提测质量，我就这么多人，就这么多时间，我怎么搞的定？
会后我跑去问老大，“单元测试和提测质量到底哪个更重要？在项目时间紧的情况下，是不是更应该让开发优先保证提测质量，而不应该去要求那些项目指标，对吗？”
老大问我，“你觉得单元测试和提测质量是二选一的关系吗？”
我说，“好像的确不能算这种关系，但又说不上来是什么关系。”
老大说，“你和开发其实都弄混淆了，我们先来简单看下什么是单元测试
通过写测试代码去测试功能代码的过程就是做单元测试。
我们再站在质量管理的角度去看研发过程，质量保证工作的前置，问题修复的成本肯定是越早越低。
拿制造业举例：检测工作都是从最初小的零部件生产开始的，那时候发现的问题修复起来很容易，但如果等很多小的零部件被组装成了成品之后，再去做检测，那时候发现的问题修复起来就会复杂很多，成本也会增加很多。
再看现在的互联网产品发布要求：
交付要求的提高，让以往在软件编码过程中，要等所有独立的单元模块组装成完整的系统才能交付的过程已经不太适用了，这个过程已经慢慢地变为一个持续性地过程，也就是持续集成。
持续集成的第一步就是自动构建，想要保证自动构建的成功，就需要有合格的单元代码，想要单元代码合格，就需要单元测试的保障。所以，质量高且覆盖率高的的单元测试是后续系统持续集成的基础，是保障合格输入的重要手段。研发模型的升级，比如测试驱动开发（Test-Driven Development，TDD）是敏捷开发中的核心实践之一，这里的测试，指的也就是单元测试。
- 根据被测对象的功能要求编写一段最简单的、必然会执行失败的单元测试代码。
- 开发最简单的、可以让单元测试代码执行成功的功能代码。
- 重构代码，让代码满足功能需求。
- 修改单元测试代码，增加新的用例，让执行结果从成功再次变为失败。
- 修改和重构代码，让执行再次成功。
所以，提测质量其实是目标要求，而单元测试则是保证达到该目标要求的一种手段，所以根本就不存在什么单元测试和提测质量哪个更重要这种问题。”
《告诉你如何从执行测试到管理测试》带你迈出第（24）步！，点击这里可查看完整地图
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
