2011-08-08 39 views
1

因此,假設我正在編寫一個API來製作美味的糖霜蛋糕。這些都很好,並且有文檔記錄,但偶爾會出現一個錯誤,或者用戶正在通過IRB探索圖書館,並在原型開發時發現了一個變量。使用rspec-expectations gem驗證API中的參數

這是我通常指示呼叫者一個參數不能是零/有其他方面的限制:

# Cake.rb 
def make_cake(cake_type, *arguments) 
    raise "cake_type required!" unless !cake_type.nil? 
    raise "cake_type must be in KNOWN_CAKES" unless KNOWN_CAKES.include?(cake_type) 
    # blah blah blah 
end 

不過,我最近考慮這樣的事情,使用rspec-expectations寶石:

# Cake.rb 
include RSpec::Matchers 
def make_cake(cake_type, *arguments) 
    cake_type.should_not be_nil, "cake_type required" 
    KNOWN_CAKES.should include(cake_type), "cake_type not found" 
end 

的優點:

  • 簡潔的DSL使得它成爲真正的輕鬆讀取人們開發針對API。
  • RSpec :: Expectations :: ExpectationNotMetError有一些很好的異常格式,給你預期的值與實際收到的值。

的CON(S):

  • 的RSpec ::預期:: ExpectationNotMetError可能是有點太詳細

所以,這種方法:好主意,還是壞主意?它違反了哪些設計原則?

回答

0

作爲調用者,我很驚訝從API調用返回RSpec異常。

你真的獲得很多嗎?如果您只更改爲raise 'cake type required!' if cake_type.nil?,該怎麼辦?似乎比我原來的代碼更清晰。也許你是這樣寫的,所以你會一直使用unless

難道你不能通過簡單地通過提高更好的消息來實現傳回預期值/接收值的目標 - 也許通過你自己的異常類?