※ 引述《ko27tye (好滋好滋)》之铭言：
: 我想补一个情境
: 当到新公司或转到新单位时
: 发现没有在做unit test
: 此时身经百战写过上千次unit test的你
: 会选择凭一己之力
: 引入测试框架及补完所有模组的单元测试吗？
: 当然这也代表那些高耦合的模组你要想办法拆分
: 其中改坏了算你的锅，改好没人在乎
: 而且高机率你得自己维护测试code
: 还是选择打不赢就加入？
: 我很好奇
: 大家可以分享一下吗
: 我自己是选择不改啦
底下这是比较“野性””的作法，算是实务专案的经验：
其实我觉得你到一个完全没有测试的专案，要分两个策略:
1. 补重要主线的 integration test 反正哪边常被报修就补哪边。
如果一开始补不上去就先做下一点，理论上常被报修的地方会一直出现在下一点，
累积多了就可以变成1了。
2. 假设自己是维护历史功能，提升自己维护部分的可测试性。
举实际案例好了，假设我今天再做一个算金流手续费的专案，
发现过去算手续费假设有11个地方写了11次好了，所谓的高耦合不外乎如此。
我会先写个 util 把输入跟输出“去状态化”，然后针对这个 util 写，
然后这个 util 的单位以“去状态化”成本可控，可在手边开发时间允许的范围进行。
白话文：我横竖都得手动测试，那就把手动测试的部分，
尽可能的透过 test code 来进行。
如果不想接着维护的话也很单纯，任务结束后把 test code comment 掉或移除就行。
题外话，11个地方，我会选择先取代一个地方，
然后等其他10个地方有需求变更时，一个个整并，补强测试条件。
很多人会说，那为什么不一次改11个，理由是你的开发时间跟成本允不允许。
更重要的是你的QA资源够不够，因为写正常的Test最累的是准备测试情境，
这真的是会花掉比写test更多的时间。
如果列不出完整场景，贸然修改既有的code只是在裸奔。
有需求的部分是被迫裸奔，但没需求的部分不用主动当暴露狂，
等待验证过再慢慢统一。
大原则就是：你横竖都是要测试的，只是手测还是写程式测，除了跟 gui 有关的东西，
多数的情况下写程式测试都还是比较省时间的。
更棒的地方是，在这种策略下，你往往可以用比同事少30% 的时间完成任务，
而且因为你的测试成本比较低，所以品质也会比较好，出问题的时候也更容易对焦。
然后我通常是会跟同事说我写了几个 test case，
他们愿意看就看，不愿意看我就放著。不会勉强他们加入。
如果你做不到可以用比不写测试更短的时间来完成任务，
那你学的测试根本性的就有问题，不写也罢。XD
3. 极端情况： 如果都没被报bug，需求也都很小？
那你操心他干嘛 XD