NUnit測試WPF程式的一個小技巧

今天有同事給一個WPF程式的後台邏輯寫UT，用的是NUnit架構，寫之前感覺UI不好寫UT，給後台邏輯寫UT應該是沒有什麼問題，但是寫開了才發現問題。

 

問題就出在了後台邏輯擷取資源的部分，代碼類似下面。

 

Application.Current.Resources[XXXX]

 

運行時拋出NullReferenceException，Application.Current為null。

 

很好理解，當前由於是用NUnit測試後台DLL，這時這個程式是基於WinForm的，而代碼中要獲得的是WPF Application，的確應該是null。這時才發現代碼寫得有問題——可測試性不好，但是代碼已經凍結了，不是Fix bug不可以改。（這個時候才開始寫UT，汗……）而這種代碼在DLL中也不少。怎麼辦呢？

 

Application.Current是唯讀，在UT裡先啟動原來的WPF程式？肯定不行的。唯讀其實不是問題，邪惡地想到了用反射給後面的變數直接賦值。得知道變數名啊，開啟Reflector，發現變數名叫_appInstance，好在這時多想了一個問題，這個變數是什麼時候被賦值的呢？第一感覺就是在個什麼初始化的方法裡，沒找幾個就發現就是在Appliction的建構函式裡。

 

看來不用反射了。

 

在UT的Startup方法裡加兩行代碼。

 

Application app = new Appliction();                      //這個app，就是Application.Current

Application.Current.Resources = Application.LoadComponents(…);

 

完成，這樣資源就可以被正常地訪問到了。如果沒看一下原始碼，真要傻呼呼地用反射賦值了。