之前几乎不写测试，嗯，我属于那一类人。很多时候是自己先写一个功能，然后输入一些简单案例跑一跑，如果过了，那么就……过了，可以放心继续下面的工作了。直到维护一个个前辈们的项目，而且功能不断添加，添加。问题接着出现了：按下葫芦浮起瓢，改了一个 Bug，引出了其它的 Bug。代码在修改过程中，越来越心里没底。更别说重构了。。。。
为什么要写测试？
现在的 Coder 应该都有这样的共识：写测试总比不写要好。为什么呢？因为它可以给我们带来以下好处：
- 便于整理编码思路
我们写代码，实际上使用计算机的语言来解决我们现实中的问题，方便我们的生活和工作。事实上，很不幸，现实比书本上描述地复杂得多。不是每个人都可以很快在头脑里对现实问题迅速抽象出来而且恰到好处的。
在写具体写代码之前，如果先按接口写测试，可以保证接口的稳定性（设计好接口，也可以方便其它人并行开发），还可以发现设计的一些缺陷（比如设计不合理、复杂度高）。
思路清晰了，那么我们代码的结构也会清晰。不仅自己看着舒服，别人维护也容易。
- 减少隐藏的 Bug，提高代码质量
其实这个本质上是一个覆盖率的问题。如果测试案例覆盖了几乎所有的情况（即使这个做到是有些难度的），在开发时期，很多 Bug 就会被早早地发现了。总比被别人报告 Bug 要好很多。
- 减少重复机械操作
在开发一个功能时，如果功能是非常简单的，类似输入abc，输出 ABC 这样大小写转换的操作，写完功能之后，简单测试下还可以。如果某个功能写好后，需要一系列的输入和操作，重复起来，那就是一个灾难。
- 方便重构
在看项目中别人写的代码的时候，有时会不自主的叹气：写得什么破代码；在看大牛的代码的时候，会惊叹：写得这么如此巧妙！妙哉！妙哉！不管代码写得如何，很多已经经历过很多次的迭代、重构。好的东西总是建立在巨人的肩膀上的。
重构时，如果面对的是没有任何测试案例的代码，我们肯定在重构的过程中会战战兢兢，唯恐踩到某个雷，甚至会不知何时给自己埋下一个雷。地雷，有一天会爆的。
- 增加对项目的理解
测试需要开发对业务逻辑有相当的理解。代码建立在你对要实现什么的基础上，其次是如何实现。整个数据的流程在伴随着测试案例的增加过程中，对系统的 来龙去脉也会更加熟悉。 所谓专家，不止是技术上的牛，在业务上也是牛。如何成为大牛？千里之行始于足下。
写测试是必要的吗？
如果某个项目只有个人开发，这个项目只是个一锤子买卖或者功能十分简单，可以不写测试。现实中的项目很多都是多人合作才能完成的，曾经工作的公司一个完整的开发流程是这样的：
design=>start: 概要设计/详细设计
deliver=>end: 交付
dev=>operation: 开发
test=>operation: 测试
integrate=>operation: 集成
deploy=>operation： 上线
degign->dev->integrate->test->deliver->deploy如果在测试阶段发现问题，需要开发确认，再找集成。如果线上有问题，需要反馈给交付，再由交付找产品经理，再由产品经理 反馈给开发；之后流程再从开发开始走。不仅耗费了大量的时间，也消耗了好多 Money。
现在越来越多的开源项目在 Github 上被开放出来，如果某个项目没有单元测试的话，几乎没人用他/她的代码。为何？代码不是我写的，万一出了问题，解决 Bug 又是一堆坑。与其填别人的坑，不如自己搞。
如果你是一个勤奋的人，那么你可以不写任何测试。如果你是或者想成为聪明的懒人，那么写测试吧。 写测试可以在别人问你这次代码靠谱吗？我们可以比较有底气地回答：是的！
为什么很多 Coder 不写测试？
是啊，为什么不写测试呢？ 任务重，时间紧？不想写？我对自己的代码很有信心，完美无 Bug？
任务重，时间紧：在评估项目开发周期时，把测试时间一并考虑。为了速度，牺牲效率得不偿失。
不想写：嗯。继续不靠谱下去？
完美无Bug：是人就会犯错。写测试会让用户更加相信，说这句话不是自负，而是自信。
本系列是关于什么的
测试的内容有很多：单元测试、性能测试、集成测试等等。本系列是使用Minitest 执行测试的 CookBook。 每篇文章着力于某一方面， 一是为了自我总结，二是希望可以给其它人一些帮助。
初次写，难免有很多不足之处，望不吝指出。