※ 引述《chopinmozart (aha)》之铭言： : 大家工作上写单元测试的情况 : 1.大部分写完一个功能, 就马上完成单元测试 : 2.先把该做的功能写完, 再回来统一写单元测试 : 3.不怎麽写单元测试 : 想请问大家工作实际情况大概是哪一种QQ 你讲的三种我都做过，还有第四种：TDD 1. TAD，讲白了就是先射箭再画靶，如果你箭射对了那当然没问题 但如果你一开始就射错了还忘记拔出来，就是无效的测试 2. 同样也是TAD，这个是我们被要求做的，code不是我们写的、但我 们要帮其他team补测试。我主管也觉得很奇怪、我也觉得很奇怪， 但反正就当作读别人程式码 1跟2的重点其实不是为了验证，当然你会有机会在写测试的时候发现 一些错误，但主要目标是确保日後别人修改行为一致 3. 纯属玩火，很多公司都在玩火，还玩得炉火纯青 但不写单元测试有时是技术上的困难，有一本书还专门在讲这个问 题(书名我忘了，别问、基峰出的我记得)，有时也有可能是绩效考量 4. TDD，通常是我自己开自己写的模组才会这样玩，没什麽，就是玩儿 台湾经常会搞错的就是把integration test跟unit test搞错，很多人其实 是在做前者而不是後者。如果你发现你test failed时你还要找老半天才能 locate the issue，那你很可能是在做前者 但无论哪种，其实没有test的公司我觉得是最好混的 1. 你commit code不一定要负责任，出事了就说历史共业，有时业在别人身上 2. 出问题了就算知道问题在哪，可以装作找不到、混时间进度，慢慢解慢慢修 所以台湾的老板们，请不要让你的员工导入test文化，谢谢，不然这样很难混 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 37.19.205.178 (日本) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1714544032.A.DE1.html