写测试太费时间，真的值得吗？
很多人一开始接触测试驱动开发（TDD），第一反应就是：写代码已经够忙了，还要先写测试？这不是浪费时间吗？其实这就像做饭前先洗菜——看似多了一步，但能避免吃到沙子。
举个例子，小李在做用户登录功能时跳过测试，结果上线后发现密码错误提示没显示，用户全卡在登录页。如果他先写个测试验证错误提示是否出现，这种低级问题早就暴露了。
测试写了，但总失败怎么办？
有时候测试跑不过，并不是代码有问题，而是测试本身写得太死板。比如你测一个获取当前时间的函数，写成必须返回‘2023-10-05 14:30:00’，那每天运行都会失败。
正确的做法是放宽条件：
expect(result).to.include('2023'); // 只验证年份正确即可测试要验证的是逻辑，不是具体数值。
如何处理依赖外部服务的代码？
比如你的代码要调用微信支付接口，总不能每次测试都真去发起一笔支付吧？这时候就得用“模拟”（mock）。
把外部依赖替换成假对象，让它返回预设数据：
const mockPay = jest.fn().mockResolvedValue({ success: true });
window.wxPay = mockPay;
// 运行测试
expect(mockPay).toHaveBeenCalled();这样既安全又快速，还不会产生真实费用。
团队里别人不写测试，我怎么坚持？
如果你是项目里唯一搞 TDD 的人，确实会有点尴尬。可以从小处入手，比如在修复 bug 前先补个测试，证明这个 bug 确实存在，修完后再跑一遍通过——用事实说话比讲道理管用。
时间久了，大家发现你改的代码很少出问题，自然会想：“他是不是有什么秘诀？” 那时候再推 TDD 就顺理成章了。
测试覆盖率达到100%就安全了吗？
数字好看不代表质量高。有人为了凑覆盖率，写一堆无意义的测试，比如对 getter/setter 疯狂打桩，但核心逻辑却漏了。
重点不是“测了多少”，而是“测对了没有”。几个关键路径上的有效测试，远比一百个表面功夫强。