測(cè)試問題域: Test Double, 以及為什么Mock之爭(zhēng)都爭(zhēng)錯(cuò)了方向 - 切爾斯基 - 博客頻道 - CSDN.NET http://blog.csdn.net/chelsea/article/details/7176479
于是這里引入了新的問題: 手工編寫替身類太繁瑣了, 體力勞動(dòng), 重復(fù)代碼, 大量的測(cè)試用例要求大量的替身類. 尤其是測(cè)試交互的那些替身類, 要能夠記錄和斷言傳入的參數(shù), 調(diào)用順序等. 為解決這些問題需要對(duì)替身類進(jìn)行設(shè)計(jì). 而人們發(fā)現(xiàn)主流語言Java, C#等提供的語言特性可以動(dòng)態(tài)的生成這些替身類, 簡(jiǎn)化手工操作和代碼量. 于是這類工具被制造出來, 稱為mock工具.
換言之, mock工具解決的不是測(cè)試中的依賴問題, 而是實(shí)現(xiàn)依賴的測(cè)試替身手工維護(hù)成本太高的問題. (只不過其中對(duì)"如何測(cè)試交互"那部分的支持被稱為mock對(duì)象而已)
第二種變化導(dǎo)致了mock的濫用. 是的, 強(qiáng)大的工具容易被濫用: 我能夠斷言交互順序不意味著所有的測(cè)試都需要斷言順序, 我能夠斷言參數(shù)不意味著所有的測(cè)試我都去斷言參數(shù). 缺乏對(duì)應(yīng)用場(chǎng)合的識(shí)別, 缺乏對(duì)系統(tǒng)的洞察, 導(dǎo)致大量脆弱的測(cè)試. 真正重要的是識(shí)別問題, 然后選擇合適的工具. Mock工具也都支持Dummy, Stub, Fake等應(yīng)用場(chǎng)景, 不要浪費(fèi)了這些功能.