Держите DRY, но хочу повторить по разным причинам

Question

Так что в моих эволюционирующих rspecs для моей RoR модели, я закончил с двумя испытаниями точно так же:

it 'is valid when x is zero' do 
    foo = build(:foo, x: 0, y: 10) 
    expect(foo.valid?).to be_truthy 
end 
it 'is valid when y is ten' do 
    foo = build(:foo, x: 0, y: 10) 
    expect(foo.valid?).to be_truthy 
end 

Это произошло потому, что я написал спецификации для проверки x сначала, затем добавьте спецификацию для y после.

Очевидно, что время для рефакторинга. Я мог бы удалить одну из спецификаций, потому что они дубликаты: держите ее СУХОЙ.

Теперь внутренности каждой спецификации могут быть одинаковыми, но описания it различны. Я не хочу потерять содержащуюся там информацию.

Мои вопросы - приемлемо ли в этом случае сохранить неповторимые характеристики дубликатов, или я должен «объединить» их и переписать описание it? Возможно:

it 'is valid when x is zero and y is ten' do 
    foo = build(:foo, x: 0, y: 10) 
    expect(foo.valid?).to be_truthy 
end 

Но на мой взгляд, у меня теперь есть одна спецификация, которая тестирует две вещи (два Validate положений в модели Foo). Это тоже нехорошо. Там запах скрывается.

Есть ли другой подход, который я пропустил?

Answer 1

Я бы не стал беспокоиться о DRY и больше о написании спецификаций, которые фактически покрывают поведение, которое вы намереваетесь.

it 'is valid when x is zero' do 
    foo = build(:foo, x: 0) 
    expect(foo.valid?).to be_truthy 
end 

Этот пример на самом деле не распространяется на вашу валидацию вообще! Если вы прокомментируете валидацию в своей модели, она все равно пройдет.

Некоторые советы при тестировании модели валидаций:

• Избегайте использования фабрик. Просто инициализируйте с помощью .new и тестируемого атрибута.
• Тестирование как недействительного, так и допустимого ввода.
• Опишите поведение проверки, а не какие значения приемлемы.
• Проверяйте каждую проверку в изоляции - ваша интеграция и функциональные спецификации обычно охватывают проверки в целом.

---

RSpec.describe Foo do 
    describe "validations" do 
    describe 'x' do 
     it "validates that x is a number between 1 and 10" do 
     expect(Foo.new(500).valid?.errors[:x]).to include "must be less than or equal to 10". 
     expect(Foo.new(10).valid?.errors).to_not have_key :x 
     end 
    end 

    describe 'y' do 
     it "validates that y is a number that is less than 15" do 
     expect(Foo.new(500).valid?.errors[:y]).to include "must be less than 15". 
     expect(Foo.new(10).valid?.errors).to_not have_key :y 
     end 
    end 
    end 
end 

Answer 2

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

Однако, по-видимому, существует несогласованность в логике ваших тестов.

Если foo is всегда действительный, когда x равно нулю, вы должны иметь возможность отбросить значение y в первой спецификации.

it 'is valid when x is zero' do 
    foo = build(:foo, x: 0) 
    expect(foo.valid?).to be_truthy 
end 

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

it 'is valid when y is ten' do 
    foo = build(:foo, y: 10) 
    expect(foo.valid?).to be_truthy 
end 

---

Если это не так, то вы могли бы рассмотреть тестирования случаев более конкретно.

Например:

it 'allows x to equal zero' do 
    foo = build(:foo, x: 0) 
    foo.valid? 
    expect(foo.errors).to_not have_key(:x) 
end 

it 'allows y to be ten' do 
    foo = build(:foo, y: 10) 
    foo.valid? 
    expect(foo.errors).to_not have_key(:y) 
end 

Answer 3

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

Правила, связанные с практикой СУХОГО кода, не являются жесткими и быстрыми, а более эвристическими. Одной из основных целей хранения кода DRY является, прежде всего, техническое обслуживание. Когда-то люди (включая меня) чувствовали, что вы пытаетесь обеспечить, чтобы вы не повторялись нигде, ради того, чтобы не повторять себя. Если вы обнаружите, что добавляете излишнюю сложность ради того, чтобы только что-то писать что-то (мне нравится высказывание Сэнди Меца «Не так сухо», то вам нужно спросить себя: «Это действительно стоит усилий?» «Это сделать мой код более читабельным или поддерживаемым? ». Один тест, который, как мне кажется, является хорошей лакмусовой бумажкой, - это то, что экземпляры дублированного кода, которые вы написали, были написаны по разным причинам, например, этот экземпляр относится к побочному эффекту, который этот экземпляр предназначен для результата.