Письменные тесты без нарушения SRP, OCP, DRY

Question

Я стараюсь лучше понять эти три принципа.

Мой вопрос ... Как написать тесты без нарушения SRP, OCP и DRY?

Мой текущий дизайн нарушает DRY из-за аналогичного кода в тестовых файлах.

Я не могу объединить тестовые файлы, потому что это нарушит принцип Open/Closed. (Существует большая вероятность добавления дополнительных модулей позже)

Есть что-то, чего я здесь не хватает? Если это помогает, я использую Ruby и Minitest для этого.

Модуль файлов

a.rb:

module A 
    # does an algorithm 
end 

b.rb:

module B 
    #does another algorithm 
end 

Тестовые файлы

a_test.rb:

class ModuleATest 
    # tests the algorithm 
end 

b_test.rb:

class ModuleBTest 
    # tests the algorithm 
end 

Answer 1

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

Что касается DRY, тестовый код должен быть доступен для чтения выше всего остального, так что это нормально, чтобы иметь более многократное дублирование в тестовом коде, чем в обычном коде. Похоже, тестирование каждого из ваших двух алгоритмов требует дублирования, которое вы не показываете; адрес, который путем извлечения дублирования в методы тестового помощника. Но делайте это только в том случае, если он сохраняет ясность тестов.

Что касается OCP, тест должен сделать все, что ему нужно, чтобы протестировать тестируемый модуль. Если сначала вы неправильно разработали свой дизайн модуля и вам нужно разделить модуль на два или что-то еще, вам придется сделать то же самое с тестом. Поэтому не беспокойтесь о том, следуют ли ваши тесты OCP, беспокоиться о вашем обычном коде и тестах.

Что касается SRP, опять же, тест должен делать все, что ему нужно, чтобы протестировать тестируемый модуль. Если у модуля слишком много обязанностей, тогда будет и его тест. Это признак того, что модуль нуждается в рефакторинге, чтобы исправить проблему как для модуля, так и для теста.

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

Answer 2

Вот как я это сделал. OCP: Классы, которые проверяют модуль не должен быть изменен SRP: Классы только проверить модуль DRY: Создав включая модуль тестера вы можете избежать дублирования кода в тестах.

module A 
    def algorithm(foo) 
     #some implementation 
    end 
end 

module B 
    def algorithm(foo) 
     #some implementation  
    end 
end 

module Module_Tester 
    def test_module_test 
     assert_equal(@expected, @obj.algorithm(@to_test)) 
     # you test them 
    end 
end 


class ModuleATest < test_framework 
    include Module_Tester 
    def before 
     @obj = Object.new.extend(A) 
     @expected = 'Expected Outcome goes here' 
     @to_test = 'The thing to test goes here' 
    end 
end 

class ModuleBTest < test_framework 
    include Module_Tester 

    def before 
     @obj = Object.new.extend(B) 
     @expected = 'The Expected Outcome' 
     @to_test = 'The thing to test' 
    end 
end