众所周知缺陷成本和发现时间成正比。谈论缺陷预防，个人认为缺陷预防应该伴随整个软件的开发周期，从涉及到提交测试乃至上线后的日常回归机制都应该考虑缺陷预防。编码时进行单元测试对于缺陷的预防更具有积极的意义，且富有成效。
调查过十来名开发同学对于单元测试的态度。对于项目中单元测试的态度基本上分为： 1.单元测试有用，项目会进行单元测试。 2.单元测试有用，项目紧张没时间进行单元测试，我们更多的采用打日志的形式。 3.单元测试枯燥没用，项目中不进行单元测试，我们更多的采用打日志的形式。还是有一小部分开发同学会抱怨单元测试，他们认为单元测试浪费了原本就紧迫的项目时间，而且认为单元测试的意义不大。过于相信自己的日志，但是日志是在出现问题后的措施，是对于解决问题有帮助意义，然而日志并不能帮助我们预防问题的产生。如果进行充分的单元测试，代码的功能以及性能都能得到保证，同时可以避免项目过程中的“优化代码现象” 还能加快测试的进度，可以说进行单元测试意义很大。需求开发时间紧张给了开发同学不进行单元测试的理由。大的项目一般都有较充分的且有保障的评审机制，从设计到代码的review，再到测试设计，测试tc的评审。而日常呢，一般情况下开发时间比较紧急，有些甚至连基本的设计评审都没有，代码review也基本不存在，时间久了，系统里便会充斥“垃圾”代码不知道什么时候爆发，最典型的莫过于本次交易下跌到0的这次事故。缺陷预防应该从小的日常做起，如果修改代码经过单元测试，评审和review，个人认为这样个人人为事件绝对是可以避免。
在配合回归的一个优化项目中很开心的看到了，这个项目对原有系统补充了单元测试用例，而且开发都在探索积极的运用起自动化测试。其实相对于频繁的新需求，我们系统的稳定性，系统的健壮性更重要，这个是我们开发新需求的基础。开发同学进行单元测试，充分的评审，review机制，测试同学进行接口测试，再加上功能上的充分自动化测试的保证一整套机制的建立才能保证系统基本的可靠运行。因此我们自身在学习编码，学习接口测试的同时，我们也应该积极的去推动鼓励开发同学进行单元测试。例如我们可以对进行单元测试的日常或者项目优先提供资源保证，我们应该督促开发同学进行单元测试。
