作者VFCanisLupus (CanisLupus)
看板Soft_Job
标题[请益] 测试程式问题
时间Sun Jul 14 21:17:20 2019
请教一下版上前辈测试方面的问题
我们公司的产品是有着微服务架构的後端服务，最近想导入测试但是在开会时对於测试的方
式与方向跟夥伴们有些意见分歧，想听听版上前辈的意见。
1. 单元测试： 我的想法是单元测试是针对每个method做测试目的是希望每个method都能符
合预期不会改a错b. 单元测试也不应该与外部相依，比如说资料库应该都用mock DAO 的方
式来测试。
不过夥伴认为我们应该也要连sql都一起测试，不然我怎麽知道sql是否正确？(意见不同1)
，写测试程式很容易因为测试案例不好而导致测试测的不完全，写这测试会很没意义（意见
不同2）
2. 整合测试： 老板认为有单元测试只不过方便日後重构而已，还不如来写整合测试（打HT
TP request 测试） （意见不同3）
我的想法是
意见1: 可以延到整合测试测，因为单元测试目的是在於验证程式码有无如预期进行，且应
该要可以快速测试验证。
意见2: 可以用测试覆盖率为参考依据
意见3：因为整合测试无法有效提昇覆盖率，且有环境等因素考量，也跟业务逻辑牵扯 （塞
资料顺序等等），反而门槛更高。
不知道版上前辈有什麽其他想法吗？
或者其实我观念有错误？
谢谢
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 27.242.203.105 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1563110242.A.161.html
1F：推 jack0204: 单元测试也能测SQL阿，有的框架支援记忆体储存ORM07/14 21:42
是指记忆体型的db吗？ 但我们用的是mybatis这种object mapping 的框架，用的是MySQL
怕有些MySQL 特有的语法会不支援， 再来我们还有其他微服务用到mongodb and redis
2F：推 art1: 测得不完全也比完全不测好07/14 21:43
是没错
3F：→ jack0204: 不然就是建一个stage环境配migrate执行完整测试07/14 21:43
4F：→ jack0204: 如果测试案例不好那就把他写到好阿，不然写爽的腻?07/14 21:44
是阿 不过现况是公司有一半的成员是junior 可能要费点心思了
5F：→ jack0204: 整合测试是因为测一整次很花时间，单元测试就快多了07/14 21:45
6F：推 jack0204: 单元(纯逻辑)/功能(假DB)/整合测试看你们想做到哪一步07/14 21:51
7F：→ pigcat1315: 没SDET部门就坐单元测试就好 不然测试的庞大你写不完07/14 21:55
我也这样认为，但老板认为 整合测试是要给工程师写的，不过在资源有限的公司里确实也
是这样就是了
8F：推 sojoasd: 小的浅短的建议：专案还在开发阶段时，写测试DB比较好，07/14 22:04
9F：→ sojoasd: 因爲这时期schema可能常常变动，当然就是比较麻烦。另外07/14 22:04
10F：→ sojoasd: 串接微服务可能改成其他排程task定时执行测试会比较好07/14 22:04
11F：→ sharku: 单元测试也可以测SQL 看你後端用什麽框架而定07/14 22:08
单元测试也可以测试sql吗 小弟去研究看看
※ 编辑: VFCanisLupus (27.242.203.105 台湾), 07/14/2019 22:47:00
※ 编辑: VFCanisLupus (27.242.203.105 台湾), 07/14/2019 22:50:39
12F：推 supernow: 我们这边单元测试不直接打db，是直接mock掉只验sql语法07/14 22:52
13F：→ supernow: ，跟你的想法一样，另外在整合测试里才实际连db 07/14 22:52
※ 编辑: VFCanisLupus (27.242.203.105 台湾), 07/14/2019 22:53:39
※ 编辑: VFCanisLupus (27.242.203.105 台湾), 07/14/2019 22:55:13
14F：推 supernow: 至於测试案例写不好这只能靠code review多电几次才能改 07/14 22:55
15F：→ supernow: 善 07/14 22:55
了解 感谢回覆
※ 编辑: VFCanisLupus (27.242.203.105 台湾), 07/14/2019 22:57:20
※ 编辑: VFCanisLupus (27.242.203.105 台湾), 07/14/2019 22:58:05
16F：推 sharku: 单元测试的DB只在执行时产生 测试完後删除 不连到实体DB 07/14 23:15
17F：→ pass78: h2 07/14 23:20
18F：推 lywctl: 单元测试时通常会用到mock跟假资料的方式来帮助测试 07/15 01:49
19F：→ lywctl: 1.Mock是用在跟这个method要做的事没直接相关时 比如现在 07/15 01:49
20F：→ lywctl: 测试一个修改使用者订单的数量 里面有一个function是要知 07/15 01:49
21F：→ lywctl: 道判断该使用者的权限 这时後就会用mock的方式指定使用者 07/15 01:49
22F：→ lywctl: 权限2.假如是要测试更改资料库的method时 应该是要用新增 07/15 01:49
23F：→ lywctl: 假资料的方式 并用该笔资料来做测试 而不是用mock 的方式 07/15 01:49
24F：推 art1: 假装使用者有此权限跟提供假资料，差异是权限跟资料吗？ 07/15 05:41
25F：→ supernow: 18楼的case.2我们这边会验的就是修改的程式有没有被呼叫 07/15 08:11
26F：→ supernow: 到，传进来的参数是否正确，还是不会去打db，直接打db变 07/15 08:11
27F：→ supernow: 数太多如网路、资料库健康..等，这不应该是单元测试要关 07/15 08:11
28F：→ supernow: 注的点 07/15 08:11
29F：推 adks3489: 单元测试用mock测语法，整合测试才连DB 07/15 09:55
30F：→ adks3489: 基本上是两者都要做 07/15 09:56
31F：推 lywctl: @art1 差异在於一个是直接回传一个结果 一个是产生一笔资 07/15 17:54
32F：→ lywctl: 料去做後续的测试 07/15 17:54
33F：推 lywctl: @adk 单元测试要测试的应该是输入的值相对应到输出的结果 07/15 17:56
34F：→ lywctl: 所有在case2时应该是会在测试的db里产生假资料去做测试 07/15 17:56
35F：推 lywctl: 至於提到的网路或是第三方资料 这些都是外部资料应该另外 07/15 17:59
36F：→ lywctl: 做mock 这算是case1 而资料库健康..这个应该是设计程式的 07/15 17:59
37F：→ lywctl: 问题吧 07/15 17:59
38F：→ supernow: 跟db互动应该交给 repository method,单元测试需要的db 07/15 19:34
39F：→ supernow: 资料就mock repository method取得 07/15 19:34
40F：推 lywctl: @super 假如会把跟db活动的都拆出来的话的确在测试其他me 07/15 23:25
41F：→ lywctl: thod时会用mock的方式 这也是前面提到的case1 07/15 23:25
42F：→ lywctl: 但repository method也会有单元测试 这时候他的资料就应 07/15 23:26
43F：→ lywctl: 该是要生成假资料的方式来进行 07/15 23:26
44F：→ lywctl: Ps: case1 跟case2并不一定是单独存在 实务上通常两个会 07/15 23:27
45F：→ lywctl: 一起用 07/15 23:27
46F：推 lywctl: 比如前面提到的例子 07/15 23:32
47F：→ lywctl: 测试一个function是要依据该使用者的权限 将原本订单的数 07/15 23:32
48F：→ lywctl: 量改成不同值 07/15 23:32
49F：→ lywctl: 这时候会先产生一笔订单的假资料 并且使用mock的方式指定 07/15 23:33
50F：→ lywctl: 使用者的权限 去测试这个method 07/15 23:33
51F：推 supernow: 你的例子我们这边会mock订单repository取得订单，再mock 07/16 01:02
52F：→ supernow: 权限取得权限，再mock 订单 repository更新订单後的结 07/16 01:02
53F：→ supernow: 果，单元测试还是不应该去实际打db 07/16 01:02
54F：→ supernow: 实际打db都应该交给整合测试做 07/16 01:03
55F：推 Csongs: 如果原本没有写单元测试，不如先写测整合测试，比较能快速 07/16 16:47
56F：→ Csongs: 看到成效 07/16 16:47
57F：→ Csongs: 单元测试要补的话，建议先写逻辑复杂的地方，不好写单元测 07/16 16:49
58F：→ Csongs: 试通常是因为写code的当下就没有想过如何测试，这时候要重 07/16 16:49
59F：→ Csongs: 构代码反而也麻烦 07/16 16:49