RSpe c - Когда следует использовать одно утверждение на SP c? - PullRequest
Новая
       37

RSpe c - Когда следует использовать одно утверждение на SP c?

0 голосов
/ 11 июля 2020

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

При этом разница в производительности между соблюдением этого правила и его несоблюдением значительна. Что касается времени разработки, которое со временем действительно увеличивается, и это также может привести к увеличению затрат на платформы непрерывной интеграции, такие как CircleCI.

Если мы посмотрим на этот пример теста, я написал: 

describe 'success' do
  before do
    result
  end

  it 'returns a user' do
    expect(result[0]).to eq(user)
  end

  it 'returns a success message' do
    expect(result[1]).to eq('Successfully registered')
  end

  it 'queries the user repository' do
    expect(user_repo).to have_received(:find_by).with(email: email)
  end

  it 'generates a hashed password' do
    expect(generate_hashed_password).to have_received(:call).with(password: password)
  end

  it 'creates the user in the database' do
    expect(user_repo).to have_received(:create).with(params[:user])
  end
end

И затем в том же тесте, написанном без единого правила утверждения: 

describe 'success' do
  before do
    result
  end

  it 'creates a user' do
    expect(result[0]).to eq(user)
    expect(result[1]).to eq('Successfully registered')
    expect(user_repo).to have_received(:find_by).with(email: email)
    expect(generate_hashed_password).to have_received(:call).with(password: password)
    expect(user_repo).to have_received(:create).with(params[:user])
  end
end

Мне кажется, что в данном сценарии этого правила не стоит придерживаться. SPE c не только более читабелен, но и примерно вдвое эффективнее, что имеет реальные положительные последствия.

Итак, мой вопрос - когда вам следует придерживаться правила единственного утверждения, а когда - лучшая идея сломать его?

1 Ответ

1 голос
/ 11 июля 2020

Я цитирую betterspecs.org

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

Итак, «правило» должно нарушаться всякий раз, когда плюсы не так важны, как минусы. Я думаю, что гораздо важнее построить свой тест, тщательно решая, что тестировать, а что нет, всегда помня о цели вашего теста. В конце концов, тестирование - это просто кодирование. Хороший тест должен рассказать о вашем коде, он должен дать представление о вашем намерении быть гибким в реализации интерфейса publi c.

Если для этого вам нужно поставить пару expect внутри it я бы сказал go.

...