Q: 需求變了怎么辦? 豈不是有大量測試用例需要修改?
A: 難道不是應該的嗎? 難道以前的需求文檔在需求發生變化時不需要修改? 哦, 或許它們不需要, 因為沒人會關心, 對代碼也沒什么影響, 需求文檔在度過最初的幾周后便被扔在配置庫里再也沒人管它了.
Q: 我的單元測試編譯鏈接速度很慢, 而且有些條件很難測, 比如內存不足, 或者環境很難搭建, 比如需要網絡或數據庫, 怎么解決?
A: 這是集成測試, 不是單元測試. 你一定把系統所有的組件都編譯鏈接起來了. 那么如果你的測試失敗了, 是哪一部分的問題呢?
通常單元測試需要滿足一個條件: 不依賴任何其它單元, 即隔離性. 實現手段就是在測試環境中能夠輕易的假冒依賴, 并設定依賴按照我們的意愿進行工作. 一個例子就是你的代碼依賴 malloc 獲取內存, 而你想測試內存不足的情況. 那么我們應在能夠/需要在單元測試中使用使用一個假冒的 malloc 來代替真正的 malloc, 并且我們能控制假冒的 malloc 返回 NULL 以模擬內存不足的情況. 關于如何做到這一點, 可參考一些成熟的"假冒"框架, 如 mockcpp 等.
Q: 我原來的測試都是用真實的代碼來跑, 一個測試能覆蓋多個單元. 你現在都把依賴替換掉了, 那被替換掉的模塊有問題怎么辦? 怎么保證集成真實的代碼后還能正確工作?
A: 其它單元有其它單元自己的單元測試, 各自關注自己. 集成測試像以前一樣, 該怎么測還怎么測, 并不是有了單元測試就不要其它測試了.
Q: 單元測試就是設計? 單元測試怎么能反映/代替設計 ?
A: 單元測試反映的是局部的設計, 局限于本單元以及與之交互的其它單元. 前面說的單元測試能夠反映系統的其它部分對當前單元的需求, 所謂設計就是單元之間的職責劃分, 交互和依賴關系
當你試圖測試一個單元時, 卻發現需要創建大量的其它對象, 而且按照你腦海中的實現, 有些對象是在單元內部創建的, 根本無法在測試環境中假冒它們. 這時候, 你即使只是為了減少測試的難度, 也會逼迫自己思考:
-
這個單元是否做了太多的事, 承擔了額外的職責, 違反了單一職責原則?
-
是否應該把依賴讓外界設置進來, 而不是自己在內部創建, 這樣測試時就能把依賴設置為假冒的實現?
是的, 單元測試警示你思考一下自己的設計
Q: 單元測試是設計, 還有人說源代碼是設計, 到底是測試是設計還是源代碼是設計?
A: 這實際上是另外一種角度. 源代碼就是設計的論斷基于兩個假設
如果我們認同這兩個假設, 那么軟件工程師的什么產物能夠被嚴格并且重復實現的呢? 是你的Word形式的"設計"文檔嗎? 是CAD工具畫出的UML圖嗎? 都不是, 因為它們都不精確, 有無數種實現方式, 根本談不到嚴格, 不同的開發人員會有完全不同的實現. 事實上, 只有源代碼,才能滿足這個約束. 這樣軟件的設計階段, 就是直到軟件工程師完成源代碼的那一刻, 而軟件的實施階段, 其實就只剩編譯和部署了. 跑題了.
文章來源于領測軟件測試網 http://www.kjueaiud.com/
