2013-10-04 96 views
0

在「Programming Ruby 1.9/2.0」一書中,作者給出了一個網球得分類的例子,該類將通過在實際代碼之前編寫一些RSpec測試來開發。RSpec示例 - 網球足球課程

筆者給大家介紹4個測試:

it "should start with a score of 0-0" 
it "should be 15-0 if the server wins a point" 
it "should be 0-15 if the receiver wins a point" 
it "should be 15-15 after they both win a point" 

然後筆者建議讀者應該繼續前進,通過編寫測試這樣完成等級:

it "should be 40-0 after the server wins three points" 
it "should be W-L after the server wins four points" 
it "should be L-W after the receiver wins four points" 
it "should be Deuce after each wins three points" 
it "should be A-server after each wins three points and the server gets one more" 

(實際TennisScorer類爲每位玩家添加分數並以「15-15」格式返回)。

作者是否假設代碼將像30-15,15-30,0-30,30-0等分數一樣工作100%,只要測試成功執行15-0,0- 15和15-15?換句話說,沒有必要明確地測試每個可能的分數? 作者建議40-0測試,這是有道理的,因爲40打破0-15-30公約(得分* 15),所以40-0測試足以顯示40-30,15-40等將工作以及?

另外,也許我太過於複雜,但在我的測試中添加隨機分數100000次並動態比較結果是不是更有意義擁有「隨機遊戲」? (但是我想我的測試可能容易包含一些錯誤..?)。 我認爲,如果我會爲乘法方法編寫測試(例如,我會檢查1 * 2 = 2並假設一切正常嗎?),我認爲這將是一條路。

回答

0

該點與tdd是讓你的規格和代碼隨着時間的推移以小增量增長。所以你應該從上面概述的一些簡單的事情開始。然而,隨着您的規範套件不斷增長以及您的代碼,您將會覺得需要重構代碼和規範。這是很自然的,因爲它應該是。我希望您的其中一個的代碼是對一個通用方法的單線調用,該方法將輸入傳遞給待測方法和預期結果。至少那是我經常會遇到的地方。

有了上面的規範,代碼可能無法與30-15等工作,因爲你指出。這取決於實施結果如何。在這裏添加更多的規格並重新使用下面的測試代碼是有意義的。

我建議不要在大多數情況下隨機化規格,因爲您不能保證結果。如果代碼本身具有隨機行爲,它可能是有道理的。我會嘗試將隨機性分離到一個地方,以便可以確定性地測試其餘部分。