近期的主要工作之一就是單元測試的編寫，對於從零開始的我來說真的是有一定難度。開一貼記錄一些單元測試方面的相關問題吧。
目前來看遇到的問題主要是如何把**或功能轉化成單元測試最理想的形式，這就要求**結構非常好，耦合度低。關於這點以後有經驗了再來補充。
目前比較主流的方式都是通過一些返回值或者取值來與目標期待值或閾值作對比，從而得出結論，結果與預期是否相符。中間的問題就是有些**邏輯執行的過程中，很難找到這樣乙個值來做判斷。基於此問題，想到了以下兩個方法：
一、把一些返回值為void型別的方法改為有返回值的方法
很多方法比如給一些成員變數賦值時，通常我們是不需要返回值的。但是在單元測試中，我們往往需要取得一些值來判斷我們的程式執行是否正常。之所以這樣修改主要是考慮到這樣對開發成本比較節約，我們只需要修改乙個返回型別，並且在函式執行末尾返回我們單元測試想要用的物件即可。而程式本身的執行與邏輯並不受到影響。為了便於理解，我們可以加上注釋，註明此返回值用於單元測試。
二、專門編寫單元測試取值的**
這種方法優勢在於原**邏輯絲毫不動，我們編寫一些專門用於單元測試取值或者運算的**來協助單元測試，如最簡單的get方法。但是此方法的弊端顯而易見，除日常開發外，我們還需要花大量精力和時間去寫這些方法，額外增加了開發成本。
感覺上是方法二是比較完美的解決方案，但是我很懶，想用方法一。
三、使用反射
反射的優勢在於可以直接獲取到類，類中的成員變數及方法等等。但是將此用於單元測試，還需研究。
關於單元測試的一些思考
邏輯直接了當 盡量少的依賴 乾淨利落的抽象以及直截了當的控制語句 沒有改進的餘地 以上內容都提取自 整潔之道 總結下來就是 簡單,簡潔,簡短.那麼提高程式正確性最有效的方法是什麼呢？在我看來，最有效的方法莫過於對 反覆琢磨推敲，讓它變得簡單，直觀，直到你一眼就可以看得出它不可能有問題。談程式的正確性...
單元測試的一些總結
productmodeldaoimpltest 測試類，productmodeldaoimpl 被測試類。1 實現 unitilsjunit4 public class productmodeldaoimpltest extends unitilsjunit4 2 聲名被測類得屬性 testedob...
助教 關於單元測試（二）
故事還在繼續.小張童鞋寫的程式一直未報bug，這激發了他繼續程式設計的興趣，於是乎，他又寫了個除法程式，說到除法，就不得不考慮的一種情況 除數為零怎麼辦？答 丟擲異常。所以，小張童鞋要解決兩個問題 為了解決第乙個問題 小張先寫了乙個最簡單的版本 package com.hui.demo public...