如何正確的使用Mock[1] 軟件測試
首先我不是反Mock者，但確實對應用Mock持對照慎重的態度，由于Mock是非常難于正確應用的， mock最稀有的問題在于如果!如果!如果!
有這樣一個功能，當有義務的時候，人民需要買需要買醫療保險，住房公積金和養老保險，如果失業了他只需要買養老保險：
public void requreInsurance(Insurances insurances) 【
if (people。getJob() == null) 【
insurances。add(new RetirementInsurance());
】 else 【
insurances。add(new HealthInsurance());
insurances。add(new RetirementInsurance());
insurances。add(new HouseFund());
insurances。add(new UnemploymentInsurance());
】
】
相應的Mock測試有兩種狀態需要掩飾：
× mock people對象， 如果getJob方法返回null，驗證insurances中只有包含養老保險
× mock people對象， 如果getJob方法返回Not null，驗證insurances中包含四金
在這里的Mock測試進行了如果，它的coorelation people對象在有義務的時候返回非Null的Job對象，而在沒有義務的時候返回Null，類似的代碼在任何一個項目中都可以找得到蹤跡。
問題在于這樣的如果可以被悄無聲息的破壞掉，如果有人重構了People對象， 在沒有義務時返回一個new NullJob()對象(Null Object Pattern)， 這樣重構后，失業的人也不得不買四金了，然而我們之前編寫的mock測試會100%的通過
如何解決這樣的問題呢?
功能測試是一個解決思路，由于在Mock測試中，我們始終的在層與層之間做出如果，一定需要一個端到端的測試來驗證我們的如果是否正確。功能測試解決了部分的問題， 回想上面的問題，你發現至少需要編寫兩個功能測試才能百分之百的發現剛才重構引入的bug， 如果只編寫了happen path的功能測試(有People義務的功能測試)，那你只有祈禱QA能幫你及時的找到問題了。不幸的是，由于功能測試的代價對照大，所以大多數的人都只會編寫有限的功能測試，往往這些測試僅僅用于掩飾Happy path。 對于如此簡單的問題功能測試尚且不能解決問題，更遑論我們“大型企業級超復雜”的項目呢。
另一個方法就是增添如果，回想一下我們的實現代碼：
if (people。getJob() == null) 【
。。。。
】 else 【
。。。。。
】
getJob的返回值是我們需要進行兩次如果的根源，如果沒有返回會怎樣?
文章來源于領測軟件測試網 http://www.k11sc111.com/