我从诸如 POODR 等书中看到的关于 TDD 的一般建议是不测试私有(private)方法。这个想法是调用私有(private)方法的公共(public)方法将被测试,这应该足以验证私有(private)方法。
这是有道理的,但是私有(private)方法有几个“层”深的情况呢?这是我的意思的人为示例:
public
# test this method
def foo
private1
end
private
def private1
private2
end
def private2
private3
end
def private3
# does stuff
end
我没有可以分享的真实示例,但在这种情况下,仅测试公共(public)方法 foo
是否足够好?或者像这样构造的代码是否指向一个可能更深层次的问题?
最佳答案
这背后的想法是类的内部是该类的实现细节。
您设计的示例仅向用户公开 foo 的输出。所以这是您的测试必须确保不会改变的唯一事情。
如果你用像 foo 这样的 10 种方法让整个类变干,只在内部使用一种方法,你不希望看到任何测试因为你更改为私有(private)方法而中断。只要公共(public)接口(interface)仍然有效,就无需测试内部结构。
这背后的原理是封装。您不关心您的类在幕后做了什么 - 因为您只关心它可以在量子计算机上运行并将它的数据流发送给一个人在月球上进行计算 - 只要输出正确,您的用户就会看到正确的预期结果。
任何测试私有(private)方法的尝试只会导致测试在您更改这些方法后中断。 这在很多情况下都很好,但过度测试会让您花更多的时间来修复损坏的测试,而不是提高效率,因此这条规则主要是为了给您一些回旋余地。
当然,这个建议总是视情况而定:如果您觉得这种方法有效很重要,您可能想为它编写测试。但是这些测试大多是您已经为公共(public)方法进行的测试的重复。
关于ruby-on-rails - 不测试公共(public)方法,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19222214/