Является ли рефакторинг тестов / спецификации хорошей идеей?

Question

Когда я вижу в своем тестовом коде спецификации, подобные этим для каждого контроллера:

it "#new displays input controls for topic title and keywords" do

  ensure_im_signed_in
  get :new

  assert_response :success
  assert_select "input#topic_title"
  assert_select "input#topic_keywords_input"
  assert assigns :topic
end

Я хочу реорганизовать его и заменить на какой-нибудь однострочный, как этот:

its_new_action_displays_input_form :topic, %w(input#topic_title input#topic_keywords_input)

и реализация:

def its_new_Action_displays_input_form field, inputs
  it "#new displays input controls for #{inputs.join ", "}" do
    ensure_im_signed_in
    get :new
    assert_response :success
    for css in inputs
      assert_select css
    end
    assert assigns field
  end
end

В чем преимущества сохранения подробной версии или рефакторинга в более краткую версию?

Я вижу, что единственная проблема с измененной версией заключается в том, что RSpec не показывает обратный след для неудачного теста.

Answer 1

Самый большой вопрос, который мы всегда задаем, это "кто тестирует тесты?" Вы должны обязательно провести рефакторинг своих юнит-тестов, где бы вы ни находились и на каком бы этапе вы ни находились, поскольку это помогает уменьшить сложность. Уменьшение сложности внутри ваших модульных тестов даст те же преимущества, что и снижение сложности в вашей кодовой базе. Я вижу очень мало причин, чтобы этого не делать, и много причин для этого.

Answer 2

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

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

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

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

Вместо этого сфокусируйте свой рефакторинг на коде котла.

Например, вы тестируете форму и для перехода на эту страницу вам нужно нажать на множество ссылок. Первым подходом было бы поставить все в спецификации. Много кликов.

В результате рефакторинга такого кода вся ссылка click_link будет помещена в before (: each). Используйте также контекст, чтобы уточнить.

Как это:

feature "Course" do
  context "Loged in" do
    before(:each) do
      school = School.make!
      switch_to_subdomain(school)
    end

    context "In the new course form" do
      before(:each) do
        click_link("Asignaturas")
        click_link("Nueva asignatura")
      end

      scenario "New course" do               
        fill_in(:name, :with => "Matematicas")
        click_button("Create Course")
        page.has_content?("Asignatura creada").should == true
        dbSchool = School.find(school.id)         
        dbSchool.courses.count.should == 1
      end
          scenario "New course" do               
        fill_in(:name, :with => "")
        click_button("Create Course")
        page.has_content?("Asignatura creada").should == false
        dbSchool = School.find(school.id)         
        dbSchool.courses.count.should == 0
      end


    end
  end  
end

Понимаете? Код котла не соответствует спецификации. Но хватит о спецификации, чтобы через 7 месяцев вы могли понять, что вы тестируете. Никогда не убирай утверждения.

Итак, мой ответ: Refactor Spec - это не только хорошая идея, но и необходимость. Но не смешивайте рефакторинг с сокрытием кода.

Answer 3

Моей самой первой работой вне колледжа было обновление набора модульных тестов. Им было около 7 лет, со многими устаревшими методами. Это заняло у меня восемь месяцев (их было много!), И я все еще не закончил работу. Однако мне удалось уменьшить размер файла примерно до 1/3 исходного размера и значительно упростить работу за счет рефакторинга большей части его, что помогло ускорить работу.

Итак, я бы определенно рекомендовал рефакторинг!

Answer 4

Это видео может показаться вам интересным.В этом видео Джерард Месарос рассказывает о рефакторинге юнит-тестов и рассказывает о причинах его проведения.

http://www.youtube.com/watch?v=Pq6LHFM4JvE

Джерард Месарос является автором «xUnit Test Patterns - Refactoring Test Code»

Answer 5

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

Вместо того, чтобы извлекать все из одного метода, вам может быть полезно иметь общий раздел before(:each) для общей настройки, инаписать свои собственные сопоставления и / или утверждения, чтобы объединить проверки.