1、前言
最近，在 上看到过 个调查，调查的内容是“程序员在项 开发中编写单元测试的情况”。当然， 于调查的结果，我想聪明的你已经可以猜到 。 达 58.3% 的 ， 般情况下 写单元测试，只 有偶尔的情况才会写写。16.6% 的程序员从来都 写单元测试。只有很少的 部分程序员才会在 的代码中进 单元测试，并保证 法测试通过。看到这些，你想到 么?
2:现状
虽然，这个调查可能会有些 性，但这也基本反应 国内程序员的开发现状，很少有程序员能够 较认真的去编写单元测试。 且，甚 有的程序员根本就 知道为 么要写单元测试(这 点让 我很郁闷)。他们经常会说，公司 是有测试 员嘛，测试应该是他们要做的事，我们的 作只 是开发(这位仁兄肯定没有学过软件 程)。当然，这些并 是偶然的，正如佛经 边说的“因果循 环”，有果必有因。那么，到底是 么原因，导致程序员对单元测试这么 感冒呢?
3:发现
通过与 个朋友的讨论，以及 上的调查，主要有这 种原因，导致程序员对单元测试很排斥，或
许说很 以为意。
知道怎么编写单元测试
项 没有要求，所以 编写
单元测试价值 ，完全是浪费时间 业务逻辑 较简单， 值得编写单元测试 管怎样，集成测试将会抓住所有的 bug， 着进 单元测试 在项 的前期还是尽 去编写单元测试，但是越到项 的后期就越失控
为 完成编码任务，没有 够的时间编写单元测试。编写单元测试会导致 能按时完成编码任务，
导致项 延期
很显然，这 种原因归根结底， 外乎就是 解单元测试， 认为很聪明， 懒 想去测试， 对项 的时间、进度把控 好。下 ，我将 进 分析，剖析出程序员的开发 ，以此来给朋 友们提个醒，最终聪明反被聪明误。
4:剖析
A: 知道怎么编写单元测试
这个问题在于，还没有接触过单元测试，同时，也没有体会过企业级的代码开发。 知道同时也 解单元测试能带给你 么。设想 下，当你开发完 个功能模块的时候，你如何确定你的模块没 有 bug 呢?如果涉及到具体的业务，你会执 debug 模式，然后 点 点的深 到代码中去查看
吗?如果你 直都是这样，那么你早就已经 OUT 。赶快去 解 下单元测试的 具吧，你会收获 很 的。
B:项 没有要求，所以 编写
这个问题反映出 种现象，同时也是 种习惯。项 有没有要求，只能说明项 的管 上 严格， 并 是程序员 编写单元测试的 由。他们在以往的开发中，并没有养成写单元测试的好习惯。可 想 知，他们的代码质 ，我就 敢恭维 。给个建议，尝试着写漂亮的代码，之所以因为漂亮， 是指得健康、简洁、健壮。当然，完成漂亮的代码就离 开单元测试 。
C:单元测试价值 ，完全是浪费时间
这种说法其实是错误的。为 么这么说呢?在 常的开发中，代码的完 其实并 等于开发的完 。 如果没有单元测试，那么如何保证代码能够正常运 呢?测试 员做的只是业务上的集成测试，也 就是 盒测试，对单个的 法是没有办法测试的， 且，测试出的 bug 的范围也会很 ，根本 能 确定 bug 的范围，还得去花时间来确定 bug 出在 么地 。难道这就 浪费时间 吗?甚 ，这样 的 式，时间浪费的会 多。
D:业务逻辑 较简单， 值得编写单元测试
所谓的业务逻辑 较简单，其实是相对的。当你对某 块业务逻辑很熟悉的时候，你 然会认为它
很简单。然 ，单元测试的必要性并 是仅仅在于测试代码的功能是否正确，还在于，当其他同事
在 解你的业务的时候，能够很快的通过单元测试来熟悉代码的功能，甚 去读代码，就能够
知道它做 哪些事情。因此，写单元测试 仅是解放 ， 别 。
E:项 前期还在尽 写测试，到 后期就失控
这种问题的原因在于，对项 进度、项 中的技术点研究时间、 员的沟通、业务需求的熟悉程度
等没有把控好。这个问题的出现并 是个 的问题， 是反映 项 管 中存在的问题。当然，个
的原因也存在，就是如何在有限的时间 ，提 效率。这 点需要 家好好思考 下 。我的建
议，多做计划，根据实际情况变 计划。多和项 组 、组成员进 沟通。及时反应项 中存在的
问题。
F:为 完成编码任务，没有 够的时间编写单元测试
这个问题在于，程序员领取的任务较为复杂，或者 的开发效率有待提 。其实，开发任务是包
括编码和单元测试的。在领任务的时候，应该跟据 身的能 ，跟组 或经 沟通好，以 出
定的测试时间。当然，提 的编码效率也是很有必要的。 于如何提 开发效率， 上有很多
这样的 章，这 就 再赘述 。
重要性
测试常常是程序员 分厌倦的 个活动。测试能给我们带来 么? 解这些是 常重要的，测试 可能保证 个程序是完全正确的，但是测试却可以增强我们对程序完整的信 ，测试可以让我们相 信程序做 我么期望它做的事情。测试能够使我们尽早的发现程序的 bug 和 。
个 bug 被隐藏的时间越 ，修复这个 bug 的代价就越 。在《快速软件开发》 书中已引 的研究数据指出:最后才修改 个 bug 的代价是在 bug 产 时修改它的代价的10倍。
当然，我们主要讨论的是单元测试。单元测试是 个 法层 上的测试，也是最细粒度的测试。 于测试 个类的每 个 法都已经满 法的功能要求。在开发中，对于 开发的模块，只有 在通过单元测试之后，才能提交到 SVN 库 或者 Git 库。
应
正是由于测试在开发中的重要地位，才会在IT界刮起 TDD 的旋 。TDD，也就是测试驱动开发模 式。它旨在强调在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后， 先 思考如何对这个功能进 测试，并完成测试代码的编写，然后编写相关的代码满 这些测试 。 然后循环进 添加其他功能，直到完成全部功能的开发。
结束语
俗话说， 屋 扫，何以扫天下。开发中，我们 的代码都 能保证功能的正确性，那么还有 么效率可 呢?做再多的任务，写再多的代码也只 过是在搭鸡窝，做着机 样的重复的 作。 IT界有 个原则，DRY原则 —— Don't Repeat Yourself !只有通过对 的 作 断的检查， 断 的测试，才能 断的突破， 断的脱颖 出，当然，你才能 断的提 。
Test Day Day Up! Experience Day Day Up! And Money Day Day Up Too!
