2012-07-19 52 views
3

我很抱歉,如果這是重複的。我已經被賦予了爲該方法增加一些覆蓋範圍的任務,並被告知模擬私人List<string>財產。我的問題是:有沒有辦法測試私人領域?有什麼好的做法來測試/注入私人領域的C#

我找到的解決方案是添加新的構造函數只是爲了注入這個私人列表。我不確定這是否是正確的方式,所以任何幫助將不勝感激。

public class Class1 
{ 
    public Class1(List<string> list)//This is just for Unit Testing 
    { 
     list1 = list; 
    } 


    private readonly InjectRepository _repository; 
    // 
    public Class1(InjectRepository repository)//This is the actual constructor 
    { 
     _repository = repository; 
    } 

    private List<string> list1 = new List<string>(); 

    public void Do_Complex_Logic() 
    { 
     //list1 will be set with items in it 
     //Now list1 is passed to some other instance 
    } 
} 
+0

可能重複[如何測試通過公共方法修改的私有字段](http://stackoverflow.com/questions/3375997/how-to-test-private-fields-that-are-modified-via-公共方法)另見http://stackoverflow.com/questions/8618710,http://stackoverflow.com/questions/6694715等 – Gishu 2012-07-20 05:19:23

回答

4

類的私有邏輯應該在其行爲的公共表達式中可見。換言之,理論認爲,根本不需要測試私人領域。

沒有辦法直接測試私人領域;畢竟他們是私人的。如果您真的認爲需要測試私人領域,那麼我會建議將其作爲內部測試,並通過[InternalsVisibleTo]屬性將其公開給您的單元測試程序集。

這就是說,有框架允許這樣的事情,如TypeMock

4

不要測試私人字段或方法。測試合同的行爲 - 公共或內部方法。

這就是說,你可以嘗試:

選項A
私人成員內部並設置InternalsVisibleTo屬性被測總成。

選項B
編寫一個包裝類,將您的私有字段/方法封裝爲公共類。這種方法有一個好處,你不需要使你的私有方法成爲內部的。缺點是對於每一個私有方法你都會有一個包裝公開方法。所以方法的數量可能翻倍。

1

我不反對其他答案;但在這種情況下,我認爲最合適的做法 - 給你的代碼;是改變

「Do_Complex_Logic」

真正的問題簽名是你正在處理在List1的「國家」。如果您將List1傳遞到Do_Complex_Logic - 您的問題已基本解決。你的評論說'Do_Complex_Logic'會(大概)在List1上做一些工作,然後把它傳遞給別的東西,對吧?

使Do_Complex_Logic獲取一個List並返回一個List。現在很容易測試。而不是根據您的類中正確設置List1的狀態,您可以'注入依賴項'。

3

添加到什麼womp &奧萊克西已經說過 -

要/事實上需要測試的私有方法是一個標誌(氣味?),你的設計可能是不正確的。這是TDD(以及我個人最喜歡的)的積極副作用之一。

一個例子:

我不完全瞭解這裏的域名,但一個簡單的變化可能是,而不是Do_Complex_Logic採取任何參數,你可以有它接受和返回一個List<string>

public List<string> Do_Complex_Logic(List<string> input)

我知道 - 它是簡單,但嘗試解構您的班級,並回想起來,先考慮測試。

+0

+1 - 我同意,這通常是一個跡象,如果你出錯的跡象需要測試這個東西作爲私人。 – womp 2012-07-19 23:29:58

1

私人領域如何在第一時間做好準備?如果是通過與存儲庫交互,那麼你可能會嘲笑該對象。要做到這一點

一種方式是通過接口與存儲庫進行交互(姑且稱之爲IInjectRepository而不是一個具體的實體,然後使用類似Moq(或嘲諷的框架存在的許多過剩的一個)來填充當你調用Do_Complex_Logic之後,我假設你有一個詢問實體的方法,這樣你就可以知道它已經完成了你所期望的事情,這樣你就可以避免/減輕添加方法和這是測試類只。