※ 引述《VFCanisLupus (CanisLupus)》之铭言：
: 请教一下版上前辈测试方面的问题
: 我们公司的产品是有着微服务架构的后端服务，最近想导入测试但是在开会时对于测试的方
: 式与方向跟伙伴们有些意见分歧，想听听版上前辈的意见。
: 1. 单元测试： 我的想法是单元测试是针对每个method做测试目的是希望每个method都能符
: 合预期不会改a错b. 单元测试也不应该与外部相依，比如说数据库应该都用mock DAO 的方
: 式来测试。
: 不过伙伴认为我们应该也要连sql都一起测试，不然我怎么知道sql是否正确？(意见不同1)
: ，写测试程式很容易因为测试案例不好而导致测试测的不完全，写这测试会很没意义（意见
: 不同2）
1. 个人偏好做法：DAO 层的任务是跟 DB 沟通，这里的 unit test 我会测 SQL。
商务层应该只关心商务逻辑，直接 mock DAO 层。这是来自单一责任原则的启发。
2. 你可以找一下你们使用的语言有没有用来跑单元测试的 embeedded db/mongo/redis。
如果没有的话可以考虑跑单元测试时用 docker 跑 db 起来测试。
3. 发现自己测试没写好，进而反省改善就是种意义。当然，这仅止于懂的反省自身的
工程师。
: 2. 整合测试： 老板认为有单元测试只不过方便日后重构而已，还不如来写整合测试（打HT
: TP request 测试） （意见不同3）
unit test 除了验证程式行为还有其他好处：
1. 未来改逻辑或加 feature 你会比较有勇气。你可以想像你每次想修改一段逻辑，
都要等整合测试跑个十几分钟才能得到反馈，是我都没勇气改了。
2. 好测试的 code 通常程式架构会比较好改：为了让程式好测/可测，你会让程式
耦合性降低，让功能责任单一，甚至你会更明确知道 DI 的重要性。
3. 有测试的 code 等于一份该 component 的使用教学，像我就会从前人的测试 code
学业务逻辑。
4. 整合测试涵盖范围太广，一个测试失败可能是网络/系统/设定/程式码任何一个地方
出问题；反观单元测试执行速度快，又可以快速定位问题。好单元，不测吗？
以上个人不负责任经验谈。
: 我的想法是
: 意见1: 可以延到整合测试测，因为单元测试目的是在于验证程式码有无如预期进行，且应
: 该要可以快速测试验证。
: 意见2: 可以用测试覆蓋率为参考依据
: 意见3：因为整合测试无法有效提升覆蓋率，且有环境等因素考量，也跟业务逻辑牵扯 （塞
: 资料顺序等等），反而门槛更高。
: 不知道版上前辈有什么其他想法吗？
: 或者其实我观念有错误？
: 谢谢
: