android單元測試好處

        許多開發者都有個習慣，經常不樂意去寫個簡單的單元測試程序來驗證本身的代碼。對本身的程序一直很是有自信，或存在僥倖心理每次運行經過後就直接扔給測試組測試了。然而每次測試組的BUG提交過來後就會發現本身的程序還存在許多沒有想到的漏洞。可是每次修改好BUG之後仍是懷着僥倖心理，認爲此次不會有bug了。而後又一次自信地提交，結果又敗了。由於這樣反覆幾回後。開發者花在找BUG和修復BUG的這些時間加起來已經比他開發這個模塊花的時間還要多了。雖然項目經理已經預留了修改BUG和單元測試的時間。可是開發者卻習慣性地在寫好代碼後就認爲任務完成了。而後等問題出來了bug改了不少次仍是修復不了的時候才和項目經理說「我碰到預想不到的問題，可能要延期發佈個人代碼「。若是這個項目不可延期，痛苦的加班就沒法避免了。

        爲何有這麼多的BUG開發者卻沒發現呢。其實開發者是人又不是機器。人非聖賢孰能無過。BUG是不可避免的，只是每次在修復一個BUG以前基本上沒法知道這個BUG是哪段代碼引發。每次定位BUG可能會耗去你一個小時仍是一天，這還要取決於你的水平了。可是若是你的每段核心程序都有單元測試代碼。你將不須要靠你的經驗去判斷或猜想BUG是由哪段程序引發。你只要運行你的單元測試方法。經過簡單判斷測試方法的結果就能夠輕鬆定位BUG了。因此從表面上看，爲每一個單元程序都編寫測試代碼彷佛是增長了工做量，可是其實這些代碼不只爲你織起了一張保護網，並且還能夠幫助你快速定位錯誤從而使你大大減小修復BUG的時間。並且這還有利你的身體健康，你將不會由於找不出BUG而痛苦不已，也將不用廢寢忘食地加班了。並且項目的進度也將盡在掌握。

        其實單元測試不只能保證項目進度還能優化你的設計。有些開發者會說，寫單元測試代碼太費勁了，比寫業務代碼還麻煩。但是若是強迫開發者必須寫單元測試代碼的時候。聰明且又想‘偷懶’的開發人員爲了未來能夠更方便地編寫測試代碼。惟一的辦法就是經過優化設計，儘量得將業務代碼設計成更容易測試的代碼。慢慢地開發者就會發現。本身設計的程序耦合度也愈來愈低。每一個單元程序的輸入輸出，業務內容和異常狀況都會盡量變得簡單。最後發現本身的編程習慣和設計能力也愈來愈老練了。

        其實容易測試的代碼基本上能夠和設計良好的代碼劃等號。由於一個單元測試用例其實就是一個單元的最先用戶。容易使用顯然意味着良好的設計。

        有着良好設計的項目一直是很注重代碼重用的。代碼重用的好處在這裏就很少說了。可是要作到代碼重用首先要保證被重用的單元程序必須是個很是優秀的程序，除了良好的設計，還要有詳細的文檔。另外最重要的實際上是單元測試代碼。不知道你們有沒有這樣的經歷？當你們不清楚一個API 函數如何使用而去尋找文檔的幫助時，每每會跳過大段的英文說明而去直接看文檔中提供的樣例程序，而後在本身的程序中依葫蘆畫瓢調用這個函數。那麼，您有沒有意識到，被重用的代碼若是有了單元測試代碼。你的測試代碼就能夠成爲這個函數最好的API 了。

        單元測試代碼還能夠經過簡單的事務回滾功能在生產環境上作基於真實數據的測試而不用擔憂會產生沒必要要的數據。利用這樣的測試代碼咱們能夠在發佈程序後check 剛纔的發佈是否成功。以往發佈的時候咱們常常會碰到一種比較尷尬的狀況，當咱們將程序發佈到正式環境上後，咱們每一個人內心一直仍是有點後顧之憂。由於咱們不能在正式環境上運行咱們的程序，只能被動地等待客戶操做事後才知道發佈的程序是否正常。這種狀況讓咱們很是被動，若是運氣好可能不出什麼問題，但是一旦客戶在正式環境上發現報了個系統異常之類的錯誤或者出現錯誤數據，那就後果很嚴重了，這將影響到產品的聲譽，顯然這樣也是很沒面子事。若是咱們運行過單元測試代碼，萬一有問題咱們就能夠主動的發現而且修改後從新發布。而其有時候就算有問題也多是一些比較低級的錯誤，或者多是發佈問題形成。基本上很快就能解決掉！這樣咱們不就高枕無憂了嗎！

        不少研究結果代表，bug發現的越晚，修改它所須要的成本就越高，所以從成本角度來看，應該儘量早地查找和修改bug。或許有人會有異議？程序員把bug全找出來了，測試組幹嗎？其實測試組進行的是集成測試，這樣的測試沒法全面的考慮到每一個單元被調用時用的各類輸入參數。就像一輛汽車，對每一個零件進行測試是必須的。對組裝好的汽車進行測試是沒法代替每一個零件的單獨測試。或許對組裝好的汽車進行測試能夠發現某些零部件的問題。可是這個時候發現了問題就須要把汽車拆了換零件再裝上。形成的成本可想而知。

轉自：http://blog.csdn.net/u013104413/article/details/46333959