关于测试的若干思考
我一直以为是我们做得不够专业，没想到不写单元测试是国内科技公司的技术风格，不过小团队在实践这种风格时总有种小马拉大车的感觉，往往是一两个测试工程师要负责一个产品的多端应用，甚至是多个产品，所以很多时候产品上线前只能通过冒烟测试简单验证一下功能。这种操作还是很经济的，通常都不会有什么大问题，可能是因为大部分时候上线的都是些可有可无的功能，直到某次老板想给客户演示产品功能，那些沉睡的 bug 才被瞬间唤醒。
如果老板追究责任，我们大概又会听到那两句经典的台词，
“在我电脑上是好的呀”
“我测试的时候是好的呀”
大部分时候他们说的都是真话，bug 也不是在第一次提交代码的时候出现的，而是在后续开发其它功能或解决其它 bug 的时候未对某个被遗忘了的功能做处理导致的。
此外，完全依赖测试人员还容易让开发人员养成当甩手掌柜的习惯，有些功能未自行验证就提交测试了，这种行为在产品迭代过程中就极容易产生摩擦，影响协作。
写单元测试也不是没有问题，最直接的问题就是开发周期变长了。写测试代码就好像是另一个专业似的，需要准备测试数据，需要用到和写功能代码不一样的技术，还需要有比写功能代码更多的耐心，有时候为了让代码方便测试还需要做相应的更改。
重构代码也可能导致部分单元测试需要重写，内心不够强大的同事可能就会选择再单独写一个或几个方法实现功能，或者直接注释掉报错的测试，于是本来需要通过测试发现问题的，最后问题反而又被隐藏了。
不管我们写多少单元测试都无法完全避免 bug 的出现，不知道是不是这个原因大部分企业更愿意把测试工作交给测试团队，给研发团队留出更多的时间开发新功能，或者这只是一种盲目地跟风，又或者只是想在出问题的时候找个背锅侠而已。
虽然我一直很推崇单元测试，但自己在这方面却没有多少积累，我的经验是在时间允许的情况下尽量多写测试，但是这种经验完全依赖个人的主观判断，没有办法形成标准或规范，我自己也遇到过注释掉测试代码先解决线上问题的时候，不知道大家的测试都是怎么做的，遇到紧急情况时又是怎么处理的？