论测试的重要性
如今程序员群体赶上了中国最庞大的农民群体，大街上随便抓一把，十有八九是程序员，还一个刚从某国企离职报名参加软件培训班。我想码农的称号或许就是这么来的吧。
在外行人看来，程序员是一个成天对着电脑倒腾着代码、看着Terminal上行云流水般的打印、过着不修边幅的日子外加超负荷的码农。
在内行人看来，程序员是一个成天面对QA的"质疑"、PM的"夺命催"以及DEVs的"吐槽"，扛着身心压力的苦行僧。
在我看来，程序员应该是：
手持神剑，心怀善念，胸有成竹、有理有据并且合情合理地跟QA、PM、DEV斗智斗勇的战士。
要摆脱QA的质疑、DEVs的吐槽以及PM的夺命催，除了那些不容易掌控的客观因素，我们可以从自身发力，加强自身的"核心肌群"，呈现出自己的应有的专业态度，编写出高质量的代码，从而促成高质量的交付。
如何交付高质量的代码？
首先，我们可以摆出苦行僧的心态，平日里练就一身好把式：如Clean Code、Refactor、OOD及FOP。即便这样，牛逼哄哄的程序员也不敢说自己的代码百分之百没有缺陷。
怎么办，两个参考原则：
- 编写完代码多问自己一句："真的可靠地完成目标了吗？" 怎么问，写个测试来提问。这便是 测试覆盖。
- 编写代码之前先问自己一句："怎么样才算完成目标了呢？" 怎么问，同样写个测试来提问。这便是 TDD + 测试覆盖。
测试能做什么
要知道测试能做什么，首先我们需要知道测试是什么（它在测什么）？它能给我们带来什么价值？以及人力成本那么昂贵，我们为什么还要花时间去编写这些上不了产品的测试代码？
程序员总喜欢倒腾点代码来开始一个话题：
public class StringUtils {
public static String toUpperCase(String source) {
if (source == null) {
return null;
}
return source.toUpperCase();
}
}
class StringUtilsTest {
@Test
void convert_to_upper_case() throws Exception {
assertThat(StringUtils.toUpperCase("unit-test"), is("UNIT-TEST"));
}
}
这一小段测试代码所做的事情是在验证StringUtils#toUpperCase方法的功能正确性。
顺便用一句话来形容单元测试：
开发人员编写一小段代码，用于检验被检测代码的一个很小的、很明确的功能是否正确。
广义上的测试并不总是像上面这段代码这么简单，熟为人知的 测试金字塔 将测试分为三大类，单元测试位于测试金字塔底端，旨在传达单元测试应该来得更凶猛一些，而它们正是由开发人员亲手编写出来。本文也是围绕单元测试来开展。
测试的价值何在
经常听开发人员说："我对我的代码非常有信心。"理由往往充分且单一：单元测试是老大，老大罩着我不怕。（当然，专业的QA始终能发现DEV很难察觉到的Defect，难免会惊起一脸狐疑：老大不灵了吗！回首代码，觉漏某一Case）。
所以单元测试能够增强你写代码的信心。都说自信是成功者必不可少的特质。当你对代码充满信心之后，你的潜能无形中被激发（你会发现你敲代码的速度都会变快），这样你工作效率的提高促使你更加轻松地完成工作。身心受益便会产生一连串良性的"蝴蝶效应"。
测试的两个无形价值就体现出来了：
1. 增强我们写代码的信心。
2. 让我们更加轻松的完成工作，身心收益。
再来说说有形的代码。缺陷减少了则证明你的代码质量提高了，代码质量衡量指标总离不开可读性、可扩展性、可维护性。这三个指标的增强反映了良好的代码整洁度、OO设计、模块化等。实践证明，这些良好的设计往往不是一蹴而就的，而当你为一个类或方法编写单元测试却举步维艰的时候，你就应该考虑去改良你的设计了。
理想情况下，编写完的代码应该是可以工作的。但现实并不那么美好，当你在验证代码正确性的时候遇到问题，你就不得不频繁地启用调式模式，而调试正是吞噬你宝贵时间的恶魔。此时我们要拔出单元测试这把神剑，使出浑身解数将恶魔驱赶到尘封的黑暗角落，从而缩减我们花在调式上的时间。
那么，测试的两个有形的价值也体现出来了：
3. 改良我们的设计。
4. 缩减我们花在调式上的时间。
在敏捷开发领域，文档（需求文档，详细设计文档等）是罕见之物。当一个新人半途加入项目的时候，在没有太多文档的情况下，阅读测试代码便是一个很好的开始。当然，前提是我们的测试代码必须是可靠的，并且具有良好的可读性。单元测试的第五项不可小觑的价值就被体现出来:
5. 测试即文档。
不写测试又如何
有一种声音："单元测试代码写得再漂亮，也终究不是产品代码，在部署到生产环境时会被无情的抛弃掉！"
所以被这种声音迷惑的人开始信奉了长（测）话（试）短（少）说（写），短（甚）话（至）不（不）说（写）的信仰。这只是经过修饰得以传播的一种声音，而背后做支撑的总有那么几大派系。
无辜派
1. 我并不清楚代码的行为，你叫我怎么测试呢？
2. 这些代码命名都能够通过编译啊！
个性派
1. 测试代码不是我的工作，这不应该由专门的人去做吗？
2. 公司请我来是为了写代码，而不是写测试的。
同理派
1. 如果我让QA人员没有工作，那么我会觉得很内疚的！
仔细推敲这三大派系，甩出几个问题就能让这些借口不攻自破：
1. 如果连代码的行为都不清楚，写出来的代码意义何在？
2. 通过编译就代表能正常工作吗？
3. 你可以不写测试，但你写的代码不断被QA找出Defect，作为DEV名声信誉何在，难道写出可靠的代码也不是你的职责吗？
4. 公司的确不是雇你来写测试的，那公司是顾你来调试bug的吗？
5. 试问QA会喜欢一个交付的代码存在很多Defect的DEV吗？我想QA也宁愿代码可靠到让他ta"无事可做"，从而去做一些功能测试、性能测试、验收测试等。
让我觉得值得一提的是常规派的看法：
1. 编写单元测试太花时间了，项目结束时再说吧！
2. 运行测试时间太长了！
"编写单元测试太花时间了，等测试结束后再说" 听起来是一个很合乎情理的想法。而在软件开发项目上存在一个这样的魔咒:
一推再推的事情，往往都是不会去做的事情。
不去做的原因可能是重视度不够，被和谐掉了，也可能是最后想去做也没有时间去做。不管出于什么原因，不写测试存在潜在的风险。
实践证明，随着时间推移，产品的功能性的变化趋势受测试代码编写的时机的影响如下图所示：
好想法抵挡不住现实的打击，代码库随着项目的进展越发复杂，由于没有测试的保护，一些不良的设计偷偷溜了进来，代码越发娇气，慢慢地没有人敢去动它。最糟糕的结果可能是，DEVs顶着巨大交付压力，唯唯诺诺的写着代码，而灾难正在酝酿，交付最终失败。
所以，只有当测试代码并行于产品代码，甚至可以采用TDD。测试的几大价值才有可能被体现出来，从而能够为我们的产品保驾护航。
就我个人经验，半TDD的编码方式，在一个Story上所花的总时间不会多余没有测试裸奔的代码。或许刚开始会觉得有点拖慢节奏，操练多了，它的威力就会彰显出来了。
测试也写了，可是运行时间太长了又带来了另一个苦恼？
细谈该苦恼可以单独写一篇文章了。我的确见过测试运行时间很长，每次验证一次跑上半个多小时。下面列举一些测试加速的实践：
1. 编写更多的单元代码来代替一些不重要的集成测试和UI测试。
2. 使用Mockito、JMock等工具模拟掉依赖。
3. 并行运行测试，前提是让测试之间保持相互独立。
4. 让CI服务器去跑更耗时的集成测试和UI测试。
5. 使用契约测试来代替微服务之间的集成测试。
单元测试运行时间是毫秒级别的，如果耗时过长，你就要留意是否存在内存泄漏、资源未释放、依赖过重或者不依赖容器而启动了容器的单元测试。
挥之不去的例外
编写单元测试是一项成本低却价值很高的活动。编写它不会花掉你太多的时间，而运行它更是毫秒间的事情。极限编程推崇者正在使用TDD的方式诠释着单元测试的价值和意义。
它能带给我们信心，改良我们的代码设计，提升我们（DEVs）的声誉，为代码库保驾护航，为高质量的软件交付提供保障。但它终究不是一颗银弹。我们编写单元测试也无非是一种价值的取舍，当它给我们带来的价值低于我们付出的成本时，我们就要保持警惕了，比如思考以下两个问题：
1. 在追求漂亮的测试覆盖率数字100%的时候，思考一下它真有那么高的价值吗？
2. 在做快速的技术Spike（技术调研），思考一下不写测试是不是能让我更快的试错？
我们要理解的是单元测试背后的核心价值，从而做出正确的取舍。我们要做的是编写出有效的单元测试，让它真正地为我们创造价值。
注释
- Terminal：命令行终端
- QA：专职测试人员
- PM：项目经理
- DEV：开发人员，DEVs表示复数
- OOD：面向对象设计
- FOP：函数时编程
- TDD：测试驱动开发
- CI：持续集成
