※ 引述《chopinmozart (aha)》之铭言： : 想请问一下 : 大家工作上写单元测试的情况 : 1.大部分写完一个功能, 就马上完成单元测试 : 2.先把该做的功能写完, 再回来统一写单元测试 : 3.不怎麽写单元测试 : 想请问大家工作实际情况大概是哪一种QQ 原则上要写测试的话我会用很古老的 TDD 的方式做，先写测试之後再写实作。 现在的话则是写完测试之後 Copilot 就帮我写完一半了，然後就开始 review copilot 的 code 了。 目前经验上能不能写测试的话我认为有三个维度会是主要影响关键，提供参考： 1. 文件是否齐全 2. 设计是否经常变动 3. 该功能会被是否不容易被其他方式侦测错误 文件是否齐全应该是主要的关键，如果前面没有文件的话搞不好测试本身就是错的了。 齐全的文件像是 json.org 的 json 格式 不齐全的像是 PM 要求要有使用者登入功能，但是没有说清楚是 username, email 或是 电话号码，电话号码可不可以有加号，密码有没有长度限制。 设计是否经常变动也是重要的主要关键，因为变动就有可能增加意外(人为失误) 像是财政部电子发票交换格式可能几年变动一次文件又明确的话就可以写测试 如果说是一次下要求密码8码然後下个 Sprint 又变成 12 码，然後再下个 Sprint 又说十码就够了，这时候测试就容易出包，或者是要思考是不是修改架构，让使用者 密码长度可以自由设定，验证条件多加入让管理者自订密码长度这样。 再来是否会被其他方式侦测错误我认为是现况下很多程式不做测试也可以用的原因 因为使用者会帮忙做测试，所以造成某些容易发生的问题自然就容易被发现找到，同时 如果该问题损害低的话，那麽就期望值而言也许损失期望值会大於写测试的成本。 举例来说，如果是比较少出现的设计，例如错误处理，就会比较建议测试，因为後面的 QA 漏测的机率比较大，如果是比较多人常用的部分，例如正常登入，再後续测试通常 能抓到，在写测试的优先顺序可能就会往後。 我想这应该是 pttbbs 的程式码基本上都没测试但是还是活得好好的原因吧? --- 另外流程是否文件化或是测试程式码的数量有的时候其实是管理层责任，毕竟大脑判断 某项细节不重要就有可能忘记，所以以前某段程式码怎麽写的即使是作者本人也有可能 不记得，更不用说人员流动离职交接的状况了。 大量没有测试(或是文件)的程式码造成的问题基本上就是程式码变动的成本会随系统 架构呈现指数上升。本来要在五行里面来回测试哪一行有问题，变成在一百行里面找出 哪一行有问题。 -- 人红是非多，活益比非多。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 150.117.165.81 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1714882664.A.026.html