Использование rspec-ожидания gem для проверки аргументов в API

Question

Итак, допустим, я пишу API для приготовления вкусных замороженных тортов. Все это хорошо и задокументировано, но иногда появляется ошибка, или, возможно, пользователь просматривает библиотеку через IRB и перебирает переменную во время прототипирования.

Так я обычно указываю вызывающим абонентам, что параметр не должен быть равен нулю / имеет другие ограничения:

# 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 gem:

# 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 :: Expectations :: ExpectationNotMetError может быть немного слишком подробным.

Итак, этот подход: хорошая идея или плохая идея? Какие принципы дизайна он нарушает?

Answer 1

Будучи вызывающим абонентом, я был бы удивлен, получив исключение RSpec от вызова API.

Вы действительно много получаете?Что делать, если вы просто измените на raise 'cake type required!' if cake_type.nil?.Кажется, читать понятнее, чем ваш оригинальный код для меня.Возможно, вы написали это так, чтобы вы использовали unless оба раза?

Не могли бы вы достичь своей цели передачи ожидаемых / полученных значений, просто повышая качество сообщений - возможно, через собственное исключениеучебный класс?