模板
教程
環境
性能
功能
管理
如何更好的實施單元測試的策略(2)
test_mpool.c void test_mpool_buffer_alloc () { UNITEST_DIFFERS (mpool_buffer_alloc (handle), 0); error_inject (INJECTION_POINT_DLL_POP_HEAD, ERROR_T (ERROR_DLL_OUT_OF_NODE), null); UNITEST_EQUALS (mpool_buffer_alloc (handle), 0); error_inject (INJECTION_POINT_DLL_POP_HEAD, 0, null); }
圖5
在這個新的單元測試程序中，我們不需為正常情形的測試做什么工作(這里做了一定形式的簡化，實際的單元測試仍需要我們就正常情形進行更為細致的檢驗)，只是讓dll_pop_head函數正常工作，返回不為null的節點就行了。要讓dll_pop_head函數返回null的話，人為地向INJECTION_POINT_DLL_POP_HEAD注入點通過error_inject函數注入錯誤。error_inject函數的第一個參數是注入點;第二個參數是所注入的錯誤碼(我們約定0表示沒有錯誤)，該碼作為調用injected_error_get函數的返回值;第三個參數是所需注入的數據，該數據通過injected_error_get函數的第二個參數返回。
其次，在產品代碼中由UNIT_TESTING宏所控制的代碼并不需要有固定的格式，可以根據需要對錯誤點的行為進行定義。比如，可能對鏈表模塊進行錯誤注入時，我們只希望影響鏈表1的行為，而不想對鏈表2有任何影響，這樣的話可以將希望影響鏈表的指針注入到錯誤點中(此時需要定義一個數據結構，以便error_inject函數能傳遞多個參數)，當然dll_pop_head函數中由UNIT_TESTING所控制的代碼也得做相應的調整，使其在返回null前檢查當前的鏈表指針(即_p_dll參數)與所注入的指針是否相同。
為了能對象malloc這樣的函數也增加錯誤注入點，我們需要對之進行封裝。比如，提供osal_malloc函數，并在其中增加錯誤注入點所需的代碼。采用這種方法的結果是，我們需要很薄的一個平臺層。是否是跨平臺完全取決于項目的特點。打個比方，對于基于VxWorks實時操作系統的項目，如果平臺的編譯開發是在Linux主機上的話，則所提供的平臺層應實現跨VxWorks和Linux操作系統。千萬不要忘了，此時單元測試應在Linux主機上完成，而非VxWorks上。而對于一個構建Linux應用軟件的項目來說，如果開發也是在Linux主機上完成的話，平臺層就根本不需要考慮跨平臺問題。
引入平臺層之后，讀者或許會有兩個擔心：一是，跨平臺庫的開發需要大量的時間;二是，跨平臺的代碼又如何做單元測試?對于第一個擔心，我的解釋是：項目所使用的操作系統或C庫的系統函數具有極強的收斂性，數目很有限，與傳統單元測試所采用打樁的方式相比，我相信構建這樣的平臺層的工作量要小很多。至于第二個問題，我的建議是：由于平臺層做得很薄，功能簡單，我們可以放棄對之做單元測試。此時，單元測試的焦點應放在構建于平臺之上的軟件模塊上。
至此，錯誤注入方式的單元測試方法介紹完了?；蛟S還有讀者會問，這又不打樁，也將錯誤點處理代碼嵌入在產品代碼中，這還是單元測試嗎?實際上，單元測試的目的是為了讓被測代碼的各行和各分支能運行到以確保質量，只要達到這一目的，是否打樁或在產品代碼中嵌入測試代碼并非介定是不是單元測試的關鍵條件。我們應時刻記住，開發活動中的行為應是價值驅動的，而非形式驅動的。一個沒有價值的行式，注定是浪費，也一定會束縛思想讓我們在困境中難以找到突破的途徑。價值驅動的觀點往往會讓我們拋開束縛，獲得意想不到的效果。
最后，整理一下以錯誤注入這一方法實施單元測試的特點：
1)引入很薄的平臺層。在平臺層中增加錯誤注入點處理代碼，以便更好地對構建于之上的軟件模塊實施單元測試。時否跨平臺取決于項目，但放棄對這一平臺層進行單元測試。
2)構建于平臺之上的各軟件模塊，在合適的地方也增加錯誤注入點處理代碼，以方便對其他依賴于它的模塊實施單元測試。
3)由于不需要額外的樁代碼，所以代碼的維護開銷更低，且天然具備復用的特點。
4)由于產品代碼與測試代碼進行了一定的合并，更容易做到“無縫整合”
