作者lovdkkkk (dk)
看板Soft_Job
标题Re: [请益] 如何实现单元测试多於整合测试？
时间Sun Nov 20 16:21:22 2022
先确认一下，不知道你们是不是用一些潮潮 der 框架，
然後那框架的官方文件给的范例是看起来简洁漂亮清楚的一两行 code，
(例如 service 里一个查询 > return 结果)
然後你们把范例 copy 过来改，直接往里面塞逻辑？
如果是这样，可能需要先做的是把 CRUD 分割出去，
把所有 "用某些参数组一些查询取得查询结果" 这样的东西包出去变成方法呼叫。
这样做之後，应该就能很容易的 mock 掉 CRUD 的部份
然後我觉得更好的情况会是把商业逻辑也包出去，
这样就可以从 service 层再切出更核心更通用的 core 部份，
core 的部份不依赖於任何框架或外部环境，
只包含 "接收资料处理逻辑回传资料"
这样做之後，应该就能很单纯的直接给资料测 core 的部份，无需任何 mock
(或者说 mock 就是 testing data 本身)
然後哪一种测试要多是依你们的需要而定，
通常整合测试可以 "花较少的时间力气测较大的范围"，
如果需要的是做上 production 之前的防护网会比较适合
单元测试足够则可以 "较明确的指出目前有问题与确定正常的部份"
如果需要的是遇到问题时能快速的排查与修复就多加一些
※ 引述《a804372004 (忽冷忽热摸不着)》之铭言：
: 将单元测试实作於专案时，发现绝大部分API都是针对资料库做CRUD，这部分程式透过in
: memory 写了整合测试，越写越觉得不对劲，心想单元测试数量不是应该要最多？ 网路文
: 章、影片或实体书籍大多也在探讨如何写单元测试，整合测试资源相对少，在想是不是我
: 哪里做错了，恳请各位大神指教。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.226.175.248 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1668932484.A.DB0.html
1F：推 a804372004: 在Service层透过Repository对资料库做CRUD，商业逻辑 11/23 16:04
2F：→ a804372004: 的部份较少，也许单元测试的需求就没这麽多？ 11/23 16:07
那的确是，假如都是单纯的 API 读资料库回传结果这类操作，
基本上也没什麽东西能拿去做单元测试
单元测试我觉得有几类比较需要 :
1. 底层核心，偏 utils 的，例如 距离计算，日期的格式化或 parse 等
它们可能被广泛的用在许多地方，比较不能出错
2. 本身内部逻辑复杂的，例如依多项参数计算费用或生成合约
它们如果出错 debug 难度会较高，
有单元测试可协助快速缩小可能出问题的范围
3. 被用在很多步骤的一组流程中的，例如要打多个 API 的一组流程，
如共享交通的借还车，这类型的当有问题但整合测试测不出来时
(例如打 API 的顺序不对，整合测试也没测该顺序的 case)
若有单元测试则可快速确认是不是底层实作的问题，
如果确认不是就能很快的调整排查的方向
3F：→ peter9s3b: 越oo越容易写unittest，先写unittest，元件抽象比较高 11/29 07:00
不那麽直接
有 "好的边界与流程" 会好测试，而 OO 是实现的手法之一，
不过不是唯一的方式，也不保证使用 OO 必然能实现 "好的边界与流程"
※ 编辑: lovdkkkk (111.241.166.152 台湾), 12/01/2022 12:21:42