V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  sulfoh6  ›  全部回复第 1 页 / 共 1 页
回复总数  11
113 天前
回复了 darklinden 创建的主题 Windows 吐槽: Windows 竟然没有 rsync...
Freefilesync +1
树莓派 4B ,有源的 USB-Hub 上面接 2.5 寸移动硬盘盒,frp 连 VPS ,居家旅行、跑毒吃鸡。
J1900 系列工控机盒子,15W 功耗,体积抵一块板儿砖。
几个月前也是坏了块希捷 ST3000DM001 。现在用西数 HC320 ,定期用 FreeFileSync 同步到移动硬盘和异地存储型 VPS 。
让 Typora 充当 Joplin 的外部编辑器
253 天前
回复了 lululuxxx 创建的主题 职场话题 低代码程序媛我该不该离职
你不是低代码程序媛,你是后端(中高代码)程序媛。用你们产品的才是低代码。
256 天前
回复了 sciel 创建的主题 程序员 你见过最简洁的后台管理系统是什么样的?
我是写一个 XMPP Bot 来调后台 API ,然后从 XMPP 客户端聊天窗口发文字命令
268 天前
回复了 ling516 创建的主题 Windows 大家手机电脑互传软件用的是啥
树莓派 SFTP ,frp 到公网
293 天前
回复了 RuLaiFo 创建的主题 程序员 单元测试有必要吗?
@caixiangyu17 其实在上面多次有人提到,如果你定义的单元测试都能发现修改本模块导致其它模块出问题,那这种粒度就不属于单元测试了,已经算集成测试了。单元测试是函数(方法)粒度的,其它模块在跑用例时理应 mock 了你的方法的行为。所以,对纯函数粒度的单元测试的疑问仍然在那里。我接触过的人几乎都没法具体说出单元测试究竟对生产力起了什么助力,只能语焉不详地干巴巴重复。在资源或者时间紧张时,大家又很诚实地用行动投票,单元测试通常第一个被祭天。解放出来的时间多跑几趟人工回归测试它不香吗?
295 天前
回复了 RuLaiFo 创建的主题 程序员 单元测试有必要吗?
在这里想认真问各位一句,你们经历过多少案例,是单元测试帮助持续地发现 Bug ?或者不要求持续,就是零星的低级错误也行。

是不是很费劲也想不起来?除了那些日常改了代码之后被单元测试卡咬、被迫更新用例的往事。

再问个问题,如果你们公司 /团队经费有限、人力有限、时间有限,需要在代码审查、单元测试、集成测试、系统测试(包括但不限于)几个环节中砍掉若干环节,你会优先考虑让哪个祭天?

不管有没有写入流程,但程序员在提交代码前自己跑一遍功能,基本验证一下,可以用自己搭的模拟环境,也可以用集成的验证环境,以保证不出纰漏,这应该也算一种最佳实践了吧。效果比单元测试好得多,成本也比单元测试低得多。事实上,在前互联网时代,很多传统软件公司就是这么做的,人家造的 Bug 并没有你黑得那么多。

总是把代码质量寄托在单元测试 + 自动化测试上,也难怪互联网时代这么多的半成品在把用户当小白鼠使。如果你认为这样很合理、很现代,那我也只能说人各有志了。
295 天前
回复了 RuLaiFo 创建的主题 程序员 单元测试有必要吗?
@matrix1010
“首先,程序员是很容易犯低级错误的,就算是老司机也经常因为低级错误翻车。如果你的低级错误直到 QA 阶段才被发现是很严重的内耗,也会降低团队间的互相信任。”
//对不起,我看到的是单元测试发现的低级错误本身也是极其稀少,更多的低级错误可以通过代码审查、集成测试轻松地发掘出来。因为没写 UT 而让低级错误流到 QA 阶段,本身就反映了团队的能力堪忧。

“真的无能为力吗, 还是只是你们团队的技术水平不太够,或是你只是为了糊弄一下随便写个测试?”
//或者,能否请你举出些实例,关于单元测试能发现设计问题、性能问题、并发问题?在多线程 /进程下跑的用例还算单元测试吗?

“敏捷开发配合自动化测试配合严格的 Code Review ,再加上技术实力靠谱的团队,这样才能实现真正的高质量快速迭代,你可以专注于迭代新功能,而不是担心别人加了个功能 /改个功能把你原来能用的东西改坏了。”
//技术实力真的靠谱的话,没有单元测试照样能写出高质量代码。反之,如果水平有限,靠强制式的单元测试约束也没法阻止烂代码的产生。你不能把高水平个体的脑力劳动成果归结于单元测试流程的功劳。

“也别总是黑印度工程师,国内很多工程师可能并不如印度工程师。另外国内大厂很多是依靠很大的 QA 团队进行人肉测试,才确保了你用到的东西没问题。”
//我算黑他们吗?凭实际输出的代码质量客观评价而已。很大的 QA 团队进行人肉测试,在你这里成了减分项了是吧?别忘了 Windows 10 缺陷如此之多,原因之一是因为笃信自动化测试,解散了曾有的人工测试部门。我举的例子里的印度团队,也是漂亮的自动化测试指标霸榜,可是被发现的 Bug 们可以都把人蠢哭,但凡有个人类测过一遍也不至于那样。
295 天前
回复了 RuLaiFo 创建的主题 程序员 单元测试有必要吗?
单元测试和代码质量没有必然联系。首先用例都是在白盒的前提下设计,为了刷覆盖率,有很多种办法可以很鸡贼地避开边界,流水账一样走一遍过场,把字面的覆盖率做得足够漂亮。一个团队里你不能保证每个人都会在写用例时尽心去考虑边界,总有人能糊弄出覆盖率达标的稀烂代码。但如此花费极大的时间代价去凑覆盖率,还有意义吗?

我呆过的一个 MNC 公司里很多印度团队,他们搞 pipeline 的漂亮花哨程度可以把上层哄得不要不要的,单元测试覆盖自然是完美级别的,还有各种自动集成测试。然而,服务上线以后会花样扑街,出错错到匪夷所思。经常在救火,但往往一波未平一波又起。到底是哪个环节出篓子了呢?单元测试 90%以上的代码仍然是把用户、内部用户当小白鼠,藏满各种地雷。

也许你有过体会,写单元测试过程中可以顺手解决掉几个低级错误。但基本上就到此为止了。很多设计上的问题、接口的问题、性能问题、安全问题、并发问题...,单元测试都无能为力,必须得靠人工的系统测试来暴露。所以,我们为什么又得花这么大的工作量去刷覆盖率呢?单元测试的另一个副作用是巩固强化了旧有的设计与实现,让决策人在决定是否重构时畏首畏尾,也让每一次的代码更改变得无比磨叽,强制加到构建过程里也会浪费更多的时间。

从个人经历来看,虽然只是有限的视角,但已经很明显的看到讽刺性的一幕:零单元测试的商业产品,稳定地运行在客户的环境里,缺陷率在可预期范围里。这里还包括电信级的设备。另一面是追求覆盖率的产品,都还没到客户手里,内部已经炸开花了,坑了内部合作的团队。因为伴随着单元测试的还有敏捷开发的其它要素,势必让依赖内部基础库的其它产品团队充当小白鼠。当然这并不是单元测试本身的锅,问题还是出在人身上。但单元测试充当了很鸡肋的角色。也许在某些关键的算法上,适合用单元测试去查瑕疵;而对于 CRUD 或者接口层面的代码,写单元测试纯粹是走形式。为什么要欺骗自己呢?
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1870 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 47ms · UTC 16:00 · PVG 00:00 · LAX 09:00 · JFK 12:00
Developed with CodeLauncher
♥ Do have faith in what you're doing.