RSpe c - Как проверить блок if-else в методе обновления контроллера

Question

Допустим, у меня есть база данных для хранения данных людей (имя, адрес электронной почты). И есть метод обновления в контроллере. Метод как:

  def update
    @people = People.find(params[:id])
    if @people.update(people_params)
       redirect_to people_path
    else
       render 'edit'
    end
  end

Интересно, как я могу проверить ситуацию, когда обновление не удалось? Или мне действительно нужно это проверить? Я искал его на StackOverflow, там есть ссылка , но там не сказано, стоит ли мне проверять или нет. Кто-нибудь может мне помочь? Если это можно проверить, то как? Большое вам спасибо!

Answer 1

1. Вам не нужно тестировать Ruby и внутренние компоненты Rails. Либо вы доверяете им обоим, работаете должным образом, либо вам лучше переключиться на какой-нибудь другой язык / фреймворк.

2. Если вы все еще хотите это проверить, высмеивайте все, что не связано. Вот пример того, как сделать это с rspec и flexmock.

describe '#update' do
  let(:person) { build(:people) }
  before do
    flexmock(People).should_receive(:find).once.returns person
    flexmock(person).should_receive(:update).once.returns false
  end

  it 'redirects to `edit` page' do
    ...
  end
end

Answer 2

Обычно ошибка обновления может быть вызвана тем, что сохраняемый объект недействителен в соответствии с его критериями проверки. Обычно вы проверяете критерии проверки в спецификациях модели, но при тестировании контроллера или в интеграционных тестах вы можете убедиться, что визуализация #edit происходит, когда пользователь пытается сохранить недопустимую модель.

Если модель не имеет каких-либо критериев проверки, вы, вероятно, можете вообще пропустить else render :edit. Это часть платформы Rails, которая может применяться не во всех случаях.

Вы можете протестировать сценарий сбоя обновления, попытавшись сохранить недопустимую модель. Обычно вы подтверждаете, что пользователь был правильно проинформирован о проблеме достоверности (сообщение fla sh).

Нет правильного или неправильного в том, стоит ли тестировать. Лично я бы это протестировал, б / c мне нравится TDD, и я предпочитаю переоценивать, а не занижать Многие не будут.