2014-01-02 2 views
1

Я рефакторинг моих моделей rspecs, чтобы быть «как DRY», как это возможно, что ведет к чему-то вродеКонечной DRY модель RSpec

require 'spec_helper' 

describe Model do 
    subject { build(:model) } 

    it { should be_valid } 

    it { should validate_presence_of(:description) } 
    it { should ensure_length_of(:description).is_at_least(3).is_at_most(255) } 

    it { should validate_presence_of(:position) } 
    it { should validate_numericality_of(:position).is_greater_than_or_equal_to(1) } 
end 

Теперь каждый файл начинается с

subject { build(:model) } 

    it { should be_valid } 

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

Любые предложения?

+8

Не реорганизовать тесты, чтобы быть "как можно более сухой", потому что они также нуждаются в более читаемость. Коэффициенты удобочитаемости DRY, так что, как DRY-код может быть более читаемым, DRY-тесты часто не являются. – Phlip

+0

^- Что @Danny Van Hoof сказал – kddeisz

ответ

2

Тест it { should be_valid }, кажется, тестирует только вашу фабрику. Это не очень важно для функции Модели. Подумайте о переносе этих тестов на один тест factories_spec, если вы хотите их протестировать. См.: https://github.com/thoughtbot/suspenders/blob/master/templates/factories_spec.rb

Подходящие устройства, которые вы используете в вашем примере, действительно не требуют модели, построенной с помощью FactoryGirl. Они будут отлично работать с неявным объектом по умолчанию (Model.new). Если это не так, я бы предложил определить как можно больше состояния вашего теста внутри теста, то есть внутри блоков it. Если это приведет к некоторому дублированию, пусть будет так. Особенно дорогостоящее дублирование можно извлечь для вызовов методов, которые предпочтительнее subject, let и before, потому что для них нет волшебства. Как разработчик, возвращающийся к проекту через 6 месяцев, глядя на спецификацию в строке 75, вы точно знаете, что такое настройка.

См: http://robots.thoughtbot.com/lets-not

+0

Мне нравится идея отдельного заводского тестера. Однако ваше второе замечание приводит к «смешанным» сообщениям об ошибках, так как начинают появляться ошибки проверки других атрибутов. Использование фабрики, похоже, предотвращает это ... – Danny

+0

Не следует. Эти помощники ищут наличие * правильного * сообщения об ошибке в атрибуте * correct *. –

+0

Кажется, они этого не делают. Я получаю ошибки и по другим атрибутам ... – Danny

2

Вы можете использовать RSpec shared examples:

shared_examples "a model" do 
    subject { build described_class } 
    it { should be_valid } 
end 

describe Foo do 
    it_behaves_like "a model" 
end 

describe Bar do 
    it_behaves_like "a model" 
end 
+0

Мне тоже нравится эта идея, но, похоже, она выполняется во вложенном контексте, так что субъект недоступен другим примерам. Модифицируя его на include_examples, «он должен вести себя как модель ", это можно исправить – Danny

+0

@DannyVanHoof' subject' определяется вне диапазона теста, но в том же файле достаточно плохо. Я бы призвал вас не определять 'subject' в совершенно другом файле. этот общий пример вложенный контекст - это * хорошая вещь. –

+0

Я понимаю и согласен – Danny

Смежные вопросы