烦人的单元测试
#软件测试那些事# #软件如何开发# #分享编程心得#
入职这个公司以来，第一次爆发争吵，因为单元测试的事，面红耳赤，处境非常尴尬，甲方不见得技术多么牛掰，几个wb仔争论个什么？较劲啥？
单测的作用确实非常大（同样的逻辑反复写两遍那肯定不会出啥大问题），但是不可否认的是，耗费时间耗费精力。要确保测试用例跑完，用纯单元测试，非常麻烦而且场景不一定覆盖全。如果用postman造数据，很快就可以测试出代码对不对。就目前的开发经历来看，我个人不是很看好写单元测试代码，更偏向直接造数据测接口，直接看业务结果。
矛盾点更多的不是单测写不写，而是同事的反应及其离谱。23年五月份，不知道怎么回事，A突然说要抓单测，大家开始都比较抵触，开发任务这么重，这东西性价比不高。奈何A推动领导重视这个事，也就默认大家都要遵守写单元测试，但其实执行情况还是很差，还是得依赖接口测试，页面点击等等非代码开发的方式来确保测试用例通过。今天提了一嘴，我改造了一个之前方法，在群里让测试回归一下，就发生了以下对话！
A:为啥改了这个代码逻辑，要让测试回归？你自己单测跑一下不就可以了吗。
A:把改造方案发出来，把单测代码发出来。
B:改造逻辑不复杂，一个方法拆成两个而已，该方法内部根据不同场景，有数百种情况，单测比较麻烦，覆盖不全，所以就用postman测了几种情况。
晨会开始…
在晨会上B提出这个问题，单测耗时多，性价比不高，postman测试效果更好一下，请问如何平衡。会议上有新过来的甲方架构师，甲方另三个研发背景人员，b觉得在晨会上提出该疑虑，更能有效解决该问题。
晨会上……
架构师说看具体情况，单测未必能覆盖全场景，看之前怎么做的团队规划，只要保重测试用例能通过就可以。
甲方A开发说，单测确实多场景很麻烦，可以不写。
甲方B开发说，是这样的，覆盖不全，还麻烦。
晨会结束……
A发了大火，质问小团队，大家对单测看法，为啥遵守情况那么差。（在北京的开发小团队都是wb仔）大家对单测都不是很认同！！（也许是还没用对方法吧）
A:单测是保重代码质量的前提，没有单测，我合并代码的时候，我不知道你测没测过。A：出现生产问题，就是大家单测没做好。
A:出现生产问题，如果没有单测，那你没有任何借口。
C：单测也覆盖不了所有场景啊，我对着代码测，也测不出来问题啊，我本来就在验证错误的逻辑。
A:这是人的问题，你人有问题，和单测没关系！
D：单测确实比较费时间，而且也不见得覆盖的全。
最后a说，既然大家都这么认为，那就大家看着办吧，不写也可以。
离大谱的来了，因为B在晨会上提了这个事，晨会有架构师，他们不在北京，只有外包开发团队在北京，a认为在晨会说单测的事情，让广州的领导觉得北京团队不行！以此为依据疯狂指责B
a质问，既然23年五月份已经同意了严格单测的规定为啥不执行？当时为啥不提出来疑问？这个时候怎么反水了？
对于a这种离大谱的发言，表示很费解！
有以下疑问
1.晨会（每日站会）的作用是什么？
2.什么样的规则是执行了有问题，还不能提出疑问的！
3.架构师领导到那个级别，有些问题，是你不说，人家就不知道吗？
4.出现问题捂住不说，就是一个优秀团队吗？
5.自己提出的规定，自己严格遵守了吗？
