При тестировании с помощью rspec, где ставить общие "методы тестовой утилиты"?

Предположим, у вас есть торговый сайт, который продает виджеты. Однако инвентарь каждого виджета ограничен, поэтому важно постоянно обновлять номер "widget.number_still_available".

Я хотел бы написать тест rspec по строкам

it "always displays the correct number still available" do

   # Assume there is a before method that sets up a widget with 5 available

   widget.number_still_available.should == 5

   # User "[email protected]" purchases 2 widgets
   widget.number_still_available.should == 3

   # User "[email protected]" purchases 1 widget
   widget.number_still_available.shhould == 2

   # User "[email protected]" cancels purchase of 1 widget
   widget.number_still_available.should == 4
end

Я хотел бы иметь возможность писать методы только для тестирования, которые выполняют методы "покупки" и "отмены". Эти действия не соответствуют каким-либо "реальным" методам в моих моделях по целому ряду причин (наиболее существенно, что в PHP существует развязанная внутренняя система, которая выполняет часть действий по покупке и отмене).

Где правильное место для ввода этого кода при использовании RSpec? В огурце я мог бы написать пару шагов - но я не уверен, какой правильный эквивалент для RSpec.

Ответ 1

Я бы предложил создать новый файл в spec/support под названием purchase_helpers.rb и поместить в него этот контент:

module PurchaseHelpers
  def purchase_widgets(user, count=1)
    # Code goes here
  end

  def cancel_purchase(user, count=1)
    # Code goes here
  end
end

RSpec.configure do |c|
  c.include PurchaseHelpers
end

Преимущество этого, а не выключение его в spec/spec_helper.rb заключается в том, что он не переполняет этот файл большим количеством кода, не связанного с настройкой RS-кода. Разделение вещей - лучший способ сделать что-то.

Ответ 2

Вы можете удалить monkeypatch в spec_helper.rb или непосредственно в верхней части файла спецификации, если он используется только для одного файла.

Было бы более понятно и безопасно создавать вспомогательные методы, которые используют существующие методы класса, а не monkeypatching классы.