先确认一下，不知道你们是不是用一些潮潮 der 框架，
然后那框架的官方文件给的范例是看起来简洁漂亮清楚的一两行 code，
(例如 service 里一个查询 > return 结果)
然后你们把范例 copy 过来改，直接往里面塞逻辑？
如果是这样，可能需要先做的是把 CRUD 分割出去，
把所有 "用某些参数组一些查询取得查询结果" 这样的东西包出去变成方法呼叫。
这样做之后，应该就能很容易的 mock 掉 CRUD 的部份
然后我觉得更好的情况会是把商业逻辑也包出去，
这样就可以从 service 层再切出更核心更通用的 core 部份，
core 的部份不依赖于任何框架或外部环境，
只包含 "接收资料处理逻辑回传资料"
这样做之后，应该就能很单纯的直接给资料测 core 的部份，无需任何 mock
(或者说 mock 就是 testing data 本身)
然后哪一种测试要多是依你们的需要而定，
通常整合测试可以 "花较少的时间力气测较大的范围"，
如果需要的是做上 production 之前的防护网会比较适合
单元测试足够则可以 "较明确的指出目前有问题与确定正常的部份"
如果需要的是遇到问题时能快速的排查与修复就多加一些
※ 引述《a804372004 (忽冷忽热摸不著)》之铭言：
: 将单元测试实作于专案时，发现绝大部分API都是针对数据库做CRUD，这部分程式透过in
: memory 写了整合测试，越写越觉得不对劲，心想单元测试数量不是应该要最多？ 网络文
: 章、影片或实体书籍大多也在探讨如何写单元测试，整合测试资源相对少，在想是不是我
: 哪里做错了，恳请各位大神指教。