同样是新手，有错请指教.
理想当然是db的部分除了db测试以外，其它功能测试都mock掉。
但是常常很多功能（至少以我目前开发的系统来说），很多功能是depend on db output，也就是 db的结果是某功能的input。这时如果要mock db，变成要另外准备一份静态的资料，而且每次sql scema改变，静态资料也要一起更新
倒不如直接连结sql，从sql取得测试资料。像前篇使用sql lite事实上io速度不会比读档慢才对
这时如果要mock db的话，变成要
※ 引述《ripple0129 (perry tsai)》之铭言：
: 单元测试是测试程式码
: 含资料一同测试不太对
: 简单来说
: 万一程式码有错
: 资料又不小心混在一起变对的
即使连db也应该自己准备测试资料，不太可能会混了就变对的，除非你用product db，测试资料无法预期。
话说回来，无法预期的资料测试应该也很不稳吧。
: 这个会死的很莫名奇妙
: 不过理想归理想啦
: 按于现实时程
: 我也常常做整合测试
: 资料程式码一起大混测
: 爆了就当做倒霉
: 时间给多少做多少事了
: ※ 引述《Nonegrame (肥宅)》之铭言：
: : ※ 引述《VFCanisLupus (CanisLupus)》之铭言：
: : : 懂你的意思，假如说redis mongodb 那些并没有单元测试的模组或套件（我还没花时
: 间
: : : 假设），那可以用docker的方式进行。
: : : 那这样是不是违反了单元测试的F.I.R.S.T 要点的 F与I ??
: : : 微服务用的是Spring Cloud，照上面前辈这样子做的话我做单元测试要用docker 架r
: ed
: : : abbitmq MySQL mongodb （可能服务发现也要启动起来）, 这样每次测试应该是没办
: 法
: : : 内执行完了。
: : : 期间只要有任何一部分没成功启动或者连线失败都回造成测试失败。
: : : 后写测试T要点应该早就违反了，先不讨论
: : :