對Android TDD 的一些經驗總結

云少嘎嘎嘎

    前一段時間做了一些Android TDD（Test Driven Development）的工作。目前TDD好像還不是十分普及，因為它與傳統(tǒng)上先寫代碼后測試的習慣有些相背，它是先寫測試代碼后寫程序。其實要完成實現(xiàn)TDD是有一定困難的，想想吧，在寫測試代碼的時候就需要將程序的構造和邏輯都想清楚是十分困難的。但是，如果嚴格按照TDD的流程寫出來的代碼一般都會是高質量的，而且維護起來也簡單得多。目前能想到的經驗主要有以下幾條，在以后的工作中如果還有新的經驗會再添加。

    

    1.慎用反射。程序中某些成員可能在測試代碼中用得到，而程序中的成員卻是私有的而且沒有預留訪問的方法接口。這時候可以適當?shù)厥褂梅瓷渥x取出這些成員的值用于測試，但是不可以使用反射修改這些成員的值，這樣會破壞程序的完整性。在測試的覆蓋率上或許會滿足要求，但是僅僅是一種為了測試而測試，這顯然與測試的目的是相左的。

    2.測試要從用戶的角度進行。這就是說測試時程序運行的流程要和用戶使用這些程序時走的流程相同，這也是為什么不能使用反射直接為成員賦值的原因。一般說來，測試程序就是一個輸入，然后判斷一個輸出是否同預期的值相同。

    3.一般來講，一個測試用例只測試一個點，否則在同一個測試用例里不同測試點可能會互相影響。

    4.在每個測試用例運行前，都會調用setUp()方法。因此可以在這個方法里面做一些通用的準備工作。在每個測試用例運行結束后都會運行tearDown()方法，在這里面就是做一些掃尾的工作。這樣就可以保證每個測試用例運行時其環(huán)境是干凈的，各個測試用例之間互不影響。

    5.慎用靜態(tài)數(shù)組。在對service的測試中，發(fā)現(xiàn)其在第一個測試用例運行完畢調用的tearDown()中會將靜態(tài)數(shù)組的內容的清空，這樣如果后面的測試用例也用到這些靜態(tài)數(shù)組就會產生空指針錯誤，不知道這是Android的一個bug還是其出于某些原因故意這么做的。但是在service以外的測試中是不是這樣的還不清楚。

    6.測試用例的代碼要盡可能的簡單可靠。測試代碼是用來測試目標程序的，首先必須要保證測試代碼的正確性，這是測試成功的前提，如果測試代碼的可靠性不能確定，那么它的測試結果就不可靠了。一般來講，測試代碼要盡可能的簡單，這樣會減少出錯的可能性，另外測試代碼要盡可能多地使用系統(tǒng)的接口和方法，因為我們可以認為系統(tǒng)中的代碼都是可靠的，可以作為一個標準來測試我們寫的代碼。