Q: 為什么通過單元測試發現的 Bug 很少 ?
A: 單元測試不是用來發現 Bug 的, 而是用來預防 Bug 的. 如果采用 TDD, 測試用例完成之時, 產品代碼尚未編寫, Bug更無從談起.
Q: 那是否寫單元測試就能提高代碼質量了 ?
A: 關于這一點, 似乎有人不這么看, <<TDD Opinion: Quality Is a Function of Thought and Reflection, Not Bug Prevention>>. 不錯, 代碼質量并不必然關聯到單元測試, 諸如凈室軟件開發之類的方法依然可以在沒有單元測試的情況下得到高質量的代碼, 但這是另外一個問題. 或許主觀上, TDD的本質更接近于促使你把質量內建在思維中, 但客觀上, 在其它條件都相同的情況下, 單元測試依然能夠起到預防 Bug 的作用.
Q: 單元測試怎么能反映/代替需求 ?
A: 單元測試未必能直接反映宏觀上的需求, 但
而從文本的角度, 測試用例的名字就是需求的描述. 換句話說, 你從傳統的需求文檔中把描述摳出來, 放到測試代碼中作為測試用例的名字, 你便擁有了可執行的需求文檔
一個 RSpec 寫的功能測試用例 (不要懷疑, 它確實是可以運行的):
it "should show welcome message after login" do
login_as_chelsea
get :index
response.should have_text(/歡迎 chelsea/)
end
it "should not show welcome message after logout" do
logout
get :index
response.should_not have_text(/歡迎/)
end
單元測試的例子:
public void testShouldBeFreeFrom2amTo5am() throws Exception { //直接業務需求
...
}
public void testShouldThrowExceptionIfCannotFindConfigFile() throws Exception { //來自系統其它部分的需求
...
}
測試用例并不排斥業務層面的需求文檔, 一個高層的, 突出業務價值的需求/愿景描述對于快速理解系統是非常有幫助的, 但/只是測試用例以另一種方式描述了真實的系統, 它具有兩個突出的優點:
-
它不會說謊, 即永遠與系統真實的行為同步
-
它是可執行的, 它可以不知疲倦的, 成本極低的, 時時刻刻, 反反復復的追問你的系統是否符合需求
文章來源于領測軟件測試網 http://www.kjueaiud.com/