def test_code(d1,d2,d3)

end

这个放在 helper 中

#1 楼 @woaigithub 那代码不是很难读很难维护？

为什么呢？难道分开放就难读难维护了吗？那你为什么不把测试代码和应用代码放在一起呢？把所有的代码都放在一起就好了。 helper 就是让你更好维护的，职责分开了

#3 楼 @woaigithub 这样 helper 会变成垃圾桶的 相当不易于维护

你的测试是分开的，每个 controller 都有自己的测试，那么每个测试都有自己的 helper。

#5 楼 @woaigithub 我还是不能接受测试代码不在测试用例的文件里而是在一个 helper 里，在我看来，helper 应该是存放一些比较低层而且比较抽象的函数库的。

看来需要更好地方案。

#7 楼 @iBachue 请上真实代码，尤其是 it 后面引号里面的

一个字： let

#9 楼 @fredwu let +1

#9 楼 @fredwu 能否给个例子？

#8 楼 @knwang 不方便上真实代码啊 it 引号里面的内容很重要吗？

引号里的代表了你的测试思路。知道了你的思路可以帮你看怎么写合适。

真实代码不方便可以改变下比如用 posts, comments 一类的，只要是同样意思就好。

找到了这样一个办法

describe ... do
  context ... do
    shared_examples ... do
      it ... do
        ...
      end
    end

    context ... do
      include_examples ... do
        let(:d1){...}
        let(:d2){...}
        let(:d3){...}
      end
    end

    context ... do
      include_examples ... do
        let(:d1){...}
        let(:d2){...}
        let(:d3){...}
      end
    end
  end
end

虽然还是没有完全达到预期，但是已经好多了

#13 楼 @knwang 是这样的一个测试，我写了一个 gem 用来包装另一个 gem，当我向 gem 的方法中传入预定的参数时，我 assert 那个被包装的 gem 的某个方法将收到某个参数，如果那个 gem 返回某些数据，assert 我的 gem 最终将返回某些数据。it 中的内容就是当传入简单的参数时，当传入较为复杂的参数时，当传入相当复杂的参数时等等。

这种可以考虑用 should_receive, 我来帮你举个例子，比如说 gem 是 一个加法器，你的包装是把参数绝对值之后在传入加法器。

你可以写成

it "should pass the positives through" 
  Adder.should_receive( :add).with(1,2,3)
  AbsoluteAdder.add(1,2,3)
end

it "should negate the nagatives" 
  Adder.should_receive( :add).with(1,2,3)
  AbsoluteAdder.add(1,-2, -3)
end

code

#16 楼 @knwang 对，但由于测试用例较多，单个用例代码较长，那我如何减少

Adder.should_receive( :add).with(1,2,3)
  AbsoluteAdder.add(1,2,3)

这段测试代码的冗余呢？

#18 楼 @iBachue 没真实代码很难讲 我估么着你需要切割方法 重构 小块分开测试