别拿测试不当代码
写测试代码都是被逼出来的
2019年初的时候我感到自己维护了三年多的项目在失控的边缘：这三年多的需求都一股脑的堆在一起；每每改动一点都是胆战心惊，怕牵连到其它功能；上线前后痛苦难耐，而且运维一呼唤就特别紧张。
反思之后，我发现问题本质出现在没有把控好软件的交付质量，导致我的软件版本不是可重复部署的。而像这种普遍性的问题业界其实一直以来都各种解决方案，比如CI/CD(持续集成/持续交付)。
当然CI/CD作为一套发布可靠软件的系统方法在实现过程中包含了许多细节，而对于一线程序员来应用CI /CD最接近开发工作的就是编写单元测试。
像写功能代码一样写测试代码
测试代码与业务代码的重要性至少是一样的。
构建测试体系写作计划
之前写过两篇试水之作，但总觉得不满意，细想之后才觉得是违背了自己：从项目学习的准则，东拼西凑的例子既脱离实际，也难有前后一致性。
所以我决定还是从实际项目入手会更好。
我会分为以下几个模块：
- 如何编写单元测试
借助于spring-test框架，可以使得我们更便捷的在编写Spring项目的单测。
这一部分也会接触到编写测试代码中特有的概念，比如数据准备，测试替身（test double）等等
- 如何编写集成测试
如果说写单元测试仅仅保证我们以正确的方式进行开发，那么集成测试更侧重于这个功能本身是否正常，是否符合需求。
但是相比较于单元测试，集成测试需要我们的程序运行在一个类似生产的环境中，那么我们连接的中间件比如：数据库、Redis、Mq、Zookeeper应该怎么处理？是在连接测试环境么？还是能够不依赖外部环境呢？我将分享我的实践心得。
- 介绍一些测试思想
我会介绍一下我所了解的测试驱动开发（TDD），验收测试驱动开发（ATDD），行为驱动开发（BDD）。这些都是为了保证我们交付的软件是满足客户需求的
痛苦的事要经常做
我必须说写测试代码不是那么愉快的事。尤其对于刚刚学习如何测试业务代码的阶段更是难熬，你会经常很多时间花在了测试代码本身，比如：
- 设计测试用例，尽量覆盖正常和异常情况；
- 发现所有功能耦合在一起，难以测试某个方法，于是不断调整代码架构；
- 修改某个功能意味着改了业务代码之后还要去修改测试代码
做好一个“普通”的程序员
这一行里有太多天才了，而且那些天才所创造的算法所构建的精巧代码我连他们好在哪里都不知道。
我想自己再努力也成为不了那些天才，只能成为茫茫IT从业者中的一员。但是“普通”也有优劣之分：认真努力，写出靠谱健壮的代码是我们这些普通程序员所能做到的。