Writing tests without violating SRP, OCP, DRY

Question

I am trying to understand these three principles better.

My question is... How do I write tests without violating SRP, OCP, and DRY?

My current design violates DRY because of the similar code in the test files.

I can't merge the test files together because that will violate the Open/Closed principle. (There is a high probability of adding more modules later)

Is there something I'm missing here? If it helps I'm using Ruby and Minitest for this.

Module files

a.rb:

module A
  # does an algorithm
end

b.rb:

module B
  #does another algorithm
end

Test files

a_test.rb:

class ModuleATest
  # tests the algorithm
end

b_test.rb:

class ModuleBTest
  # tests the algorithm
end

I found this link that talks about [sharing examples](http://wojtekmach.pl/blog/2013/07/17/sharing-examples-in-minitest). I'll need to research this topic a bit more. — jriver27, Oct 27 '15 at 19:10

score 0 · Answer 1 · answered Nov 03 '15 at 15:35

Here is how I did it. OCP: The classes that test the module will not have to be modified SRP: The classes only test the module DRY: By creating including the module tester you can avoid duplication of code in the tests.

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

score 0 · Accepted Answer · answered Feb 08 '16 at 14:41

Test code is quite different from regular code, so although all of those design principles are generally valid in test code, their importance is different there.

Regarding DRY, test code needs to be readable above all else, so it's normal to have a little more duplication in test code than in regular code. It sounds like testing each of your two algorithms requires duplication that you're not showing; address that by extracting the duplication into test helper methods. But do that only if it preserves the clarity of the tests.

Regarding OCP, a test needs to do whatever it needs to do to test the module it's testing. If you got your module design wrong at first and have to split a module into two or something, you'll have to do the same with the test. So don't worry about whether your tests follow OCP, worry about your regular code and the tests will follow.

Regarding SRP, again, a test needs to do whatever it needs to do to test the module it's testing. If a module has too many responsibilities then so will its test. That's a sign that the module needs refactoring to fix the issue for both the module and the test.

Also, there are different kinds of tests. Integration tests by their nature have more responsibilities than unit tests.

Writing tests without violating SRP, OCP, DRY

2 Answers2