Это должен быть простой ответ, но яЯ пытаюсь найти его (проверил документацию RSpec, EverydayRails Testing с RSpec, результаты Google). В мои спецификации моделей я хотел бы включить следующие основные характеристики атрибутов:

describe Foo do
  describe "basic attributes" do
    before { @foo = create(:foo) }
    subject { @foo }

    it { should be_valid }
    it { should respond_to(:color) }
    it { should respond_to(:height) }
    it { should respond_to(:some_other_attribute) }
    it { should respond_to(:you_get_the_idea) }
    ...

Мне нравятся эти спецификации, потому что, если на моей фабрике и / или модели есть какая-то ошибка, эти спецификации помогают мне быстро ее определить.

мы включилиexpect синтаксис во всех других спецификациях, и мне нравится, как он читает, но как его использовать здесь? Один из вариантов может быть

expect(@foo).to respond_to(:color)

И другой может быть

expect(it).to respond_to(:color)

Первое включает в себя дублирование, которое избегается сshould синтаксис, но последний выглядит странно для меня (который может быть только я).

Я понимаю, что этот вопрос больше относится к стилю, чем к функциональности *, но мы, разработчики Ruby, добросовестно относимся к стилю, и я хочу придерживаться стандартных практик и иметь читаемый идиоматический код. Любая помощь приветствуется. Благодарю.

ОБНОВЛЕНИЕ: ни один из моих предложенных вариантов фактически не работает, кстати. Они оба бросаютundefined method 'expect' ошибки. Сейчас я'Я действительно смущен!

Подумав об ошибке, я понимаю,потому чтоshould спецификации выше находятся внутри однострочного блока. Тогда возникает путаница: как написать однострочный блок с ожидаемым синтаксисом? В свете этого обновления вопрос очень о функциональности, и ябудет взволнован, чтобы услышать чужие мысли.

4/2015 ОБНОВЛЕНИЕ

rspec > 3.0 добавил еще один способ обработки этих, и это звучит какrspec ~> 4.0 покончит сshould синтаксис. Пер Мирон Мастерс:

Некоторые пользователи выражают недоумение по поводу того, как это должно соотноситься с ожидаемым синтаксисом и можно ли продолжать его использовать. Он будет по-прежнему доступен в RSpec 3 (опять же, независимо от вашей конфигурации синтаксиса), но мыМы также добавили альтернативный API, который немного больше соответствует ожидаемому синтаксису:

describe Post do
  it { is_expected.to allow_mass_assignment_of(:title) }
end

is_expected определяется очень просто как ожидаемый (субъект) и также поддерживает отрицательные ожидания с помощью is_expected.not_to matcher. [...]

В RSpec 3 мыМы сохранили синтаксис must, и он доступен по умолчанию, но вы получите предупреждение об устаревании, если будете использовать его без явного включения. Это проложит путь к его отключению по умолчанию (или, возможно, извлечению в отдельный драгоценный камень) в RSpec 4, одновременно сводя к минимуму путаницу для новичков, приходящих в RSpec через старое руководство.