请教一下版上前辈测试方面的问题
我们公司的产品是有着微服务架构的后端服务，最近想导入测试但是在开会时对于测试的方
式与方向跟伙伴们有些意见分歧，想听听版上前辈的意见。
1. 单元测试： 我的想法是单元测试是针对每个method做测试目的是希望每个method都能符
合预期不会改a错b. 单元测试也不应该与外部相依，比如说数据库应该都用mock DAO 的方
式来测试。
不过伙伴认为我们应该也要连sql都一起测试，不然我怎么知道sql是否正确？(意见不同1)
，写测试程式很容易因为测试案例不好而导致测试测的不完全，写这测试会很没意义（意见
不同2）
2. 整合测试： 老板认为有单元测试只不过方便日后重构而已，还不如来写整合测试（打HT
TP request 测试） （意见不同3）
我的想法是
意见1: 可以延到整合测试测，因为单元测试目的是在于验证程式码有无如预期进行，且应
该要可以快速测试验证。
意见2: 可以用测试覆蓋率为参考依据
意见3：因为整合测试无法有效提升覆蓋率，且有环境等因素考量，也跟业务逻辑牵扯 （塞
资料顺序等等），反而门槛更高。
不知道版上前辈有什么其他想法吗？
或者其实我观念有错误？
谢谢

单元测试也能测SQL阿，有的框架支援内存储存ORM

测得不完全也比完全不测好

不然就是建一个stage环境配migrate执行完整测试如果测试案例不好那就把他写到好阿，不然写爽的腻?整合测试是因为测一整次很花时间，单元测试就快多了单元(纯逻辑)/功能(假DB)/整合测试看你们想做到哪一步

没SDET部门就坐单元测试就好 不然测试的庞大你写不完

小的浅短的建议：专案还在开发阶段时，写测试DB比较好，因为这时期schema可能常常变动，当然就是比较麻烦。另外串接微服务可能改成其他排程task定时执行测试会比较好

单元测试也可以测SQL 看你后端用什么框架而定

我们这边单元测试不直接打db，是直接mock掉只验sql语法，跟你的想法一样，另外在整合测试里才实际连db至于测试案例写不好这只能靠code review多电几次才能改善

单元测试的DB只在执行时产生 测试完后删除 不连到实体DB

h2

单元测试时通常会用到mock跟假资料的方式来帮助测试1.Mock是用在跟这个method要做的事没直接相关时 比如现在测试一个修改使用者订单的数量 里面有一个function是要知道判断该使用者的权限 这时后就会用mock的方式指定使用者权限2.假如是要测试更改数据库的method时 应该是要用新增假资料的方式 并用该笔资料来做测试 而不是用mock 的方式

假装使用者有此权限跟提供假资料，差异是权限跟资料吗？

18楼的case.2我们这边会验的就是修改的程式有没有被呼叫到，传进来的参数是否正确，还是不会去打db，直接打db变量太多如网络、数据库健康..等，这不应该是单元测试要关注的点

单元测试用mock测语法，整合测试才连DB基本上是两者都要做

@art1 差异在于一个是直接回传一个结果 一个是产生一笔资料去做后续的测试@adk 单元测试要测试的应该是输入的值相对应到输出的结果所有在case2时应该是会在测试的db里产生假资料去做测试至于提到的网络或是第三方资料 这些都是外部资料应该另外做mock 这算是case1 而数据库健康..这个应该是设计程式的问题吧

跟db互动应该交给 repository method,单元测试需要的db资料就mock repository method取得

@super 假如会把跟db活动的都拆出来的话的确在测试其他method时会用mock的方式 这也是前面提到的case1但repository method也会有单元测试 这时候他的资料就应该是要生成假资料的方式来进行Ps: case1 跟case2并不一定是单独存在 实务上通常两个会一起用比如前面提到的例子测试一个function是要依据该使用者的权限 将原本订单的数量改成不同值这时候会先产生一笔订单的假资料 并且使用mock的方式指定使用者的权限 去测试这个method

你的例子我们这边会mock订单repository取得订单，再mock权限取得权限，再mock 订单 repository更新订单后的结果，单元测试还是不应该去实际打db实际打db都应该交给整合测试做

如果原本没有写单元测试，不如先写测整合测试，比较能快速看到成效单元测试要补的话，建议先写逻辑复杂的地方，不好写单元测试通常是因为写code的当下就没有想过如何测试，这时候要重构代码反而也麻烦