同樣是新手，有錯請指教.
理想當然是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要點應該早就違反了，先不討論
: : :