前言
近期，在网上看到过一个调查，调查的内容是“程序猿在项目开发中编写单元測试的情况”。当然，至于调查的结果，我想聪明的你已经能够猜到了。高达 58.3% 的比例，普通情况下不写单元測试。仅仅有偶尔的情况才会写写。16.6% 的程序猿从来都不写单元測试。仅仅有非常少的一部分程序猿才会在自己的代码中进行单元測试，并保证方法測试通过。看到这些。你想到了什么？
现状
尽管，这个调查可能会有些片面性，但这也基本反应了国内程序猿的开发现状，非常少有程序猿可以比較认真的去编写单元測试。并且。甚至有的程序猿根本就不知道为什么要写单元測试（这一点让我非常郁闷）。他们常常会说，公司里不是有測试人员嘛，測试应该是他们要做的事，我们的工作仅仅是开发（这位仁兄肯定没有学过软件project）。
当然，这些并非偶然的，正如佛经里边说的“因果循环”。有果必有因。那么，究竟是什么原因，导致程序猿对单元測试这么不感冒呢？
发现
通过与几个朋友的讨论，以及网上的调查。主要有这几种原因。导致程序猿对单元測试非常排斥。也许说非常不以为意。
- 不知道怎么编写单元測试
- 项目没有要求，所以不编写
- 单元測试价值不高。全然是浪费时间
- 业务逻辑比較简单，不值得编写单元測试
- 无论如何，集成測试将会抓住全部的 bug，用不着进行单元測试
- 在项目的前期还是尽量去编写单元測试，可是越到项目的后期就越失控
- 为了完毕编码任务，没有足够的时间编写单元測试。编写单元測试会导致不能按时完毕编码任务，导致项目延期
非常显然，这几种原因归根结底，无外乎就是不了解单元測试，自觉得非常聪明，自己懒不想去測试。对项目的时间、进度把控不好。以下。我将一 一进行分析，剖析出程序猿的开发心理。以此来给朋友们提个醒，终于聪明反被聪明误。
剖析
不知道怎么编写单元測试
这个问题在于，还没有接触过单元測试，同一时候，也没有体会过企业级的代码开发。不知道同一时候也不了解单元測试能带给你什么。设想一下，当你开发完一个功能模块的时候，你怎样确定你的模块没有 bug 呢？假设涉及到详细的业务。你会运行 debug 模式，然后一点一点的深入到代码中去查看吗？假设你一直都是这样，那么你早就已经 OUT 了。
赶快去了解一下单元測试的工具吧，你会收获非常大的。
项目没有要求，所以不编写
这个问题反映出了一种现象。同一时候也是一种习惯。
项目有没有要求。仅仅能说明项目的管理上不严格，并非程序猿不编写单元測试的理由。他们在以往的开发中，并没有养成写单元測试的好习惯。
可想而知。他们的代码质量，我就不敢恭维了。
给个建议。尝试着写美丽的代码，之所以由于美丽。是指得健康、简洁、健壮。当然，完毕美丽的代码就离不开单元測试了。
单元測试价值不高。全然是浪费时间
这种说法事实上是错误的。
为什么这么说呢？在日常的开发中，代码的完工事实上并不等于开发的完工。假设没有单元測试，那么怎样保证代码可以正常执行呢？測试人员做的仅仅是业务上的集成測试。也就是黑盒測试，对单个的方法是没有办法測试的，并且，測试出的 bug 的范围也会非常广，根本不能确定 bug 的范围，还得去花时间来确定 bug 出在什么地方。
难道这就不浪费时间了吗？甚至，这种方式，时间浪费的会很多其它。
业务逻辑比較简单，不值得编写单元測试
所谓的业务逻辑比較简单。事实上是相对的。当你对某一块业务逻辑非常熟悉的时候，你自然会觉得它非常easy。
然而，单元測试的必要性并非只在于測试代码的功能是否正确，还在于。当其它同事在了解你的业务的时候，可以非常快的通过单元測试来熟悉代码的功能，甚至不用去读代码，就行知道它做了哪些事情。因此，写单元測试不仅是解放了自己，更方便了别人。
项眼下期还在尽量写測试，到了后期就失控了
这样的问题的解决办法在于，对项目进度、项目中的技术点研究时间、人员的沟通、业务需求的熟悉程度等没有把控好。
这个问题的出现并非个人的问题，而是反映了项目管理中存在的问题。
当然，个人的原因也存在。就是怎样在有限的时间里，提高效率。
这一点须要大家好好思考一下了。我的建议，多做计划，依据实际情况变更计划。
多和项目组长、组成员进行沟通。及时反应项目中存在的问题。
为了完毕编码任务，没有足够的时间编写单元測试
这个问题在于，程序猿领取的任务较为复杂。或者自己的开发效率有待提高。事实上，开发任务是包含编码和单元測试的。
在领任务的时候，应该跟据自身的能力。跟组长或经理沟通好，以便留出一定的測试时间。当然。提高自己的编码效率也是非常有必要的。至于怎样提高开发效率。网上有非常多这种文章，这里就不再赘述了。
重要性
測试经常是程序猿十分厌倦的一个活动。
測试能给我们带来什么？了解这些是很重要的。測试不可能保证一个程序是全然正确的，可是測试却能够增强我们对程序完整的信心，測试能够让我们相信程序做了我么期望它做的事情。
測试能够使我们尽早的发现程序的 bug 和不足。
一个 bug 被隐藏的时间越长，修复这个 bug 的代价就越大。在《高速软件开发》一书中已引用了大量的研究数据指出：最后才改动一个 bug 的代价是在 bug 产生时改动它的代价的10倍。
当然，我们主要讨论的是单元測试。单元測试是一个方法层面上的測试，也是最细粒度的測试。用于測试一个类的每个方法都已经满足了方法的功能要求。在开发中，对于自己开发的模块。仅仅有在通过单元測试之后，才干提交到 SVN 库 或者 Git 库。
应用
正是因为測试在开发中的重要地位，才会在IT界刮起了 TDD 的旋风。TDD，也就是測试驱动开发模式。它旨在强调在开发功能代码之前，先编写測试代码。
也就是说在明白要开发某个功能后，首先思考怎样对这个功能进行測试。并完毕測试代码的编写。然后编写相关的代码满足这些測试用例。
然后循环进行加入其它功能。直到完毕所有功能的开发。
工具
说了这么多。那么都有什么工具（框架）能帮助我们完毕可反复的单元測试呢？以下我就介绍几个经常使用的。这里仅仅介绍 Java 语言的。
其它语言的请问谷老师（Google）。
JUnit 在日常开发中还是非经常常使用的，并且 Java 的各种 IDE （Eclipse、MyEclipse、IntelliJ IDEA）都集成了 JUnit 的组件。当然，自己加入插件也是非常方便的。JUnit 框架是 Java 语言单元測试当前的一站式解决方式。这个框架值得称赞，由于它把測试驱动的开发思想介绍给 Java 开发者并教给他们怎样有效地编写单元測试。
TestNG，即Testing Next Generation，下一代測试技术。是依据JUnit和NUnit思想，採用 jdk 的 annotation 技术来强化測试功能并借助XML 文件强化測试组织结构而构建的測试框架。TestNG 的强大之处还在于不仅能够用来做单元測试，还能够用来做集成測试。
这里不过介绍一下有哪些最经常使用的 Java 单元測试工具。对于怎样使用这些工具，在兴许的博客中会有介绍。这里就不再多说了。
有兴趣的请关注兴许的文章。
结束语
俗话说，一屋不扫。何以扫天下。开发中。我们自己的代码都不能保证功能的正确性，那么还有什么效率可言呢？做再多的任务，写再多的代码也仅仅只是是在搭鸡窝，做着机器一样的反复的工作。IT界有一个原则，DRY原则 —— Don't Repeat Yourself ！
仅仅有通过对自己的工作不断的检查，不断的測试。才干不断的突破，不断的脱颖而出，当然，你才干不断的提高。
Test Day Day Up！ Experience Day Day Up！ And
Money Day Day Up Too。
哎呀妈呀，中国式英语又出来了！
