※ 引述《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 的程式码基本上都没测试但是还是活得好好的原因吧?