在不违反SRP,OCP,DRY的情况下编写测试

时间:2015-10-27 15:18:24

标签: testing dry solid-principles single-responsibility-principle open-closed-principle

我想更好地理解这三个原则。

我的问题是......   如何在不违反SRP,OCP和DRY的情况下编写测试?

由于测试文件中的代码类似,我当前的设计违反了DRY。

我无法将测试文件合并在一起,因为这会违反开放/封闭原则。 (以后添加更多模块的可能性很高)

这里有什么我想念的吗? 如果它有助于我使用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

2 个答案:

答案 0 :(得分:0)

我是这样做的。 OCP:   不必修改测试模块的类 SRP:   这些类只测试模块 干:   通过创建包含模块测试器,您可以避免在测试中重复代码。

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

答案 1 :(得分:0)

测试代码与常规代码完全不同,因此尽管所有这些设计原则在测试代码中通常都是有效的,但它们的重要性却不同。

关于DRY,测试代码需要高于一切可读性,因此在测试代码中比在常规代码中有更多的重复是正常的。这听起来像测试你的两个算法中的每一个都需要你没有展示的重复;通过将重复提取到测试助手方法来解决这个问题。但只有在保持测试的清晰度的情况下才这样做。

关于OCP,测试需要做任何它需要做的事情来测试它正在测试的模块。如果您的模块设计最初出错并且必须将模块拆分为两个或类别,那么您必须对测试进行相同的操作。因此,不要担心您的测试是否遵循OCP,担心您的常规代码,测试将随之而来。

关于SRP,测试需要做任何它需要做的事情来测试它正在测试的模块。如果一个模块有太多的责任,那么它的测试也是如此。这表明该模块需要重构来解决模块和测试的问题。

此外,还有不同类型的测试。集成测试本质上比单元测试更有责任。