Применение принципа DRY в RSpec

Все ок, только по мне так примеры не очень. Спасибо за поднятую хорошую тему!

Let схож с subject’ом, но используется для объявления методов.

Может быть вы в курсе. Чем именованные subject отличается от let? Тем, что однострочниках распознается?

4. Собственные матчеры

Пример с матчером be_cool очень плох на мой взгляд. Вместо читаемого спека тот код, что там есть превратился в какую-то нечитаемую неинтуитивную магию, особенно, если описание матчера вынести в другое место. Мне кажется, в этом случае, лучше оставить только has_error_on, поскольку только этот пример действительно проповедует добро.

Это перевод документации что ли?

Не идеально, но очень неплохо :)

Из замечаний:

1. Про «примеры не очень» сказали, имхо имело смысл начать с let, subject и one-liner'ов, и везде ниже их использовать

2. Про shared_context не слышал, звучит интересно, но из описания тут не очень понял, как конкретно работает фича, пришлось лезть в доки, больше внимания деталям :)

3. Макросы можно было, наверное, не описывать — велика вероятность, что они скоро попадут в deprecated, а shared_example действительно целиком замещают их функционал.

4. В форматировании однострочников ошибка, там лишний отступ для It'ов и лишний end в конце :)

От себя, про важные мелочи:

Про describe: В сэмплах выше использовался describe со стрингой, но он умеет больше. В качестве параметра может принять класс klass, тогда он сам заинит subject как klass.new и будет поддерживать нужный неймспейс внутри тестов. Причем его можно дернуть внутри контекста существующих модулей, например. Очень удобно:

module Project
  module Models
    describe User do # subject стал User.new
      its(:value) { should be_nil }
      specify { expect { subject.test }.to raise_error Errors::UserError }
      # Не Project::Models::Errors::UserError
    end
  end
end

Про context: контекст — примерно то же самое, что и describe, кроме того что не изменяет subject. Хорошая практика их использовани — когда у нас контекст целиком состоит из атомарных спек (те самые one-liner'ы), а конкретное описание теста складывается из имен вложенных контекстов. См. примеры ниже про let и subject

Про let и subject: собственно отличаются они лишь тем, что subject указывает на тестируемый объект и в однострочниках expectation'ы автоматически связываются именно с ним, если вызваны не на каком-то конкретном объекте. Есть важные замечание про их природу.

let — это лямбда, которая лениво вычисляется при первом обращении внутри теста, и в let сохраняется результат вычисления. Так что если у вас есть какое-то тяжелое вычисление, которое может просадить тесты — не бойтесь запихать его в let, оно выполнится только если необходимо в тесте.

let'ы можно вызывать внутри друг друг, переопределять внутри контекста и т.д.

context "#request" do
  let(:type) { 'correct_type' }
  let(:params) { {type: type} }
  subject { Interface.new.request(params) }
  it { should be_ok }
  context "with incorrect type" do
    let(:type) { 'madness' }
    it { should_not be_ok }
  end
end

Можно хитрить и заставить let возвращать лямбду, тогда можно сократить на синтаксисе еще немного :) Не всегда это хорошо, но иногда уместно.

context "#request" do
  let(:interface_call) { ->{ subject.some_call(type) } }
  context "with incorrect type" do
    let(:type) { 'Invalid type' }
    specify { interface_call.should raise_error Errors::InvalidTypeError }
  end
end

Только стоит помнить, что let вычисляется ровно один раз. Потому если вы решите его использовать как шорт-кат для измерения какого-то значения, то вас ждет провал :)

context "#add" do
  let(:value) { subject.some_hardly_accessible_value.to_i }
  specify { subject.add(20).should chage { value }.by(20) }
  # Провалится, value вычислится один раз и больше не изменится
end

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

context "#collect_ids" do #Например, метод собирает из базы айдишники всех пользователей.
  let(:user) { Fabricate(:user) } # Фабрикатором cоздается запись про юзера в базке
  specify { User.all.collect_ids.should include user.id }
end

Эта спека провалится. Связано, очевидно, с тем, что список всех айдишников составляется до того, как будет вызвал let(:user), и на базке будет создан юзер. Соответственно делать let'ы надо без сайд-эффектов, что б на такие грабли не наступать. Ну или помнить о них. Чувствительные сайд-эффекты лучше явно указать в before.

В общем, let'ы очень удобны и довольно мощны, рекомендую их щедро использовать.

Пояснение про shared_context: Помимо того, что это переносной контекст, обращу внимание на одну фичу, которая из текста не очень ясна. Существует два метода его использования в спеках.

shared_context "shared_context", state: :a do # в метаданных указан state: :a - это важно
  # some context
end

describe "#direct include" do
  include_context "shared stuff" # прямо инклюдим shared_context в наш текущий контекст
  context "subcontext_with_a_state", state: :a do
    #some specs
  end
  
  context "subcontext_with_b_state", state: :b do
    #other specs
  end

  #оба контекста будут включать в себя shared_context
end

describe "#metadata include" do
  context "subcontext_with_a_state", state: :a do
    #some specs
  end
  
  context "subcontext_with_b_state", state: :b do
    #other specs
  end

  #только первый контекст включит в себя shared_context, так как совпадет по метадате
end

Я не 100% уверен в точности интерпретации, нет возможности потестить, но из док получается так

Из кратких замечаний наверное все %)
Еще хотел бы прочитать чужое мнение про тестирование методов с помощью should_receive — там вечные проблемы с лаконичностью и все не очень просто. Может и сам напишу вариант, попозже :)

В догонку betterspecs.org :)