同样是新手，有错请指教. 理想当然是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要点应该早就违反了，先不讨论 : : : -- : : 我测试新手啦 写单元测试时 我通常不会 mock DB : : 在使用 ORM 的状况下 很容易会执行後与预期不符的状况 : : (例如 有绑 AfterFind Hook, 验 SQL 会是对的 但捞完的结果已经被改过 ) 为什麽要绑hook，hook的问题应该在开发前就想到的。 所以tdd drive是不适合「导入」已经写完的product，应该在开发初期就规划。 : : 遇到其他外部功能还是会 mock 掉 但 DB 部分不会 : : 确保真的连到 DB 时 ORM 出来结果与 test 状况相同 : : 当然这样算是单元+整合测试的混合了 : : 如果用的框架有提供相关功能会超级方便 : : 像 php laravel 用 sqlite memory driver 实际跑起来也没多慢 sqlite对我来说算unit test, 因为资料要自己准备，感觉是静态input. : : 至於只验证 SQL 语法是否为预期也试过 但是写起来太累了 这是什麽意思啊﹖ : : 最後还是直接开 DB 连比较乾脆 : : 以上 提供参考 ----- Sent from JPTT on my Google Pixel 3a XL. --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 223.137.174.189 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1563363219.A.D7D.html