将单元测试实作于专案时，发现绝大部分API都是针对数据库做CRUD，这部分程式透过in
memory 写了整合测试，越写越觉得不对劲，心想单元测试数量不是应该要最多？ 网络文
章、影片或实体书籍大多也在探讨如何写单元测试，整合测试资源相对少，在想是不是我
哪里做错了，恳请各位大神指教。

以传统三层式架构来说我多半是测中间的商业逻辑层

看情况，只要整合测试写/改起来不累，单元测试就没那么重要数量差距不用太在意，只要好写又有效，多一点无妨

实务上，单元测试不是看数量多少，是看覆蓋率。整合测试不是工程师在开发环境写单元测试，而是在测试环境，QA写。简单说，从来不追求数量。追求覆蓋。

小公司不会有赔钱部门QA的

不用在意数量多寡 测试数量会根据你做的架构或软件类型变化是很正常的一件事 像你说你API都CRUD 那当然单元测试就都通常在测处理资料的商业逻辑 但要是那些逻辑也没啥好测就甭测了 因为本来就没啥好测 但如果你是做个图像引擎之类的东西 单元测试就会变得比较多 因为运算也比较多 合理吧

当然是直接整合测试就好 专案失控才要整天搞单元测试而且ide可以单步除错 真的要测也不用annotation的烂方式一劳永逸让专案可控才是最佳品质保证

你写db/cache用DI写 可以很方便的 mock 这些依赖但是也有不少做法是在测试时 用你的 db entity 真实建一个db 在缓存中, 这样测试有一个优点 就是确保你entity是正确的,也可以符合你实际连线的状况 缺点就是麻烦

CRUD是很制式化的技术应用 想方设法使程式码简洁且逻辑圆融 做到这一步即便你不写测试多半应用不会有错见到更多的是程式码乱七八糟写测试想hold住质量的...当然已经是屎山的就冏了别人的产品可以不必搞到这样 但有某种程度方便很多