2011-08-08 2 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 보석 사용 :

을 나는 일반적으로 매개 변수가 nil이 아니어야한다는 발신자 표시 방법

은/다른 제약이있다
# 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에는 예상 값과 실제받은 값을 제공하는 훌륭한 예외 형식이 있습니다.

죄수 (들?) :

  • RSpec에 :: 기대 :: ExpectationNotMetError 조금 너무 자세한 수 있습니다.

그래서이 접근법은 좋은 아이디어입니까 아니면 나쁜 아이디어입니까? 어떤 디자인 원칙을 위반합니까?

답변

0

호출자는 API 호출에서 RSpec 예외를 다시 얻는 것에 놀랐습니다.

정말 많이 얻습니까? raise 'cake type required!' if cake_type.nil?으로 변경하면 어떨까요? 원래 코드보다 더 명확하게 읽을 수 있습니다. 어쩌면 당신은 이렇게 쓰면 unless 두 번 사용할 수 있을까요?

예를 들어 자신의 예외 클래스를 통해 더 나은 메시지를 올리기 만하면 예상/수신 된 값을 다시 전달할 목표를 달성 할 수 없습니까?