如果一个项目通过了 Ruby 2.0.0-p648 和 Ruby 2.3.1 中的测试,是否也可以使用 2.1.8 和 2.2.3 等版本进行测试?
是否有任何语言功能在 Ruby 2.0 和 Ruby 2.3 中有效,但在例如 Ruby 2.2 中暂时不起作用或工作方式不同?
如果一个项目通过了 Ruby 2.0.0-p648 和 Ruby 2.3.1 中的测试,是否也可以使用 2.1.8 和 2.2.3 等版本进行测试?
是否有任何语言功能在 Ruby 2.0 和 Ruby 2.3 中有效,但在例如 Ruby 2.2 中暂时不起作用或工作方式不同?
您应该针对您打算在其中使用它的环境测试您的代码。Ruby 语言版本是可以变化的一件事。如果您的代码应该支持它,您也可以考虑针对 JRuby 和 Rubinius 进行测试——例如,它作为公共 gem 提供。
从逻辑上讲,对最早和最新版本的测试应该涵盖与语言功能相关的大多数失败场景(尽管不一定是所有语言错误,因为可以引入新错误)。据我所知,没有在一个版本中故意添加或删除 Ruby 功能,然后该决定在以后的版本中被逆转。除非:也许在您的生产代码中,您正在检测某个功能的存在,然后完全使用该功能 - 在这种情况下,具有该功能但不是最新状态的中间 Ruby 版本可能会失败。
可能还有其他警告,从哲学上讲,当您开始测试时,您希望避免过多合乎逻辑的“这应该有效,因为......” 思维。测试的目的是证明您的代码不会以您所涵盖的方式失败(好吧,它比这更深入,但如果它深入测试哲学,答案会变得太长)。如果您想声明“适用于从 2.0.0 到 2.3.1 的所有 Ruby MRI 版本”,那么如果您实际测试过,您会觉得更安全。事实上,当在公共场所发表这样的声明时,我通常只会说一些更接近原始事实的内容——“在 2.0.0、2.1.4 和 2.3.1 版本中测试”。
显然,收益递减。如果您在 2.1.9 中没有问题,那么您在 2.1.10 中也不太可能出现问题 - 在某些时候,检查每一个细微的变化会花费您更多的成本,甚至只是查看测试结果,而不是收益额外的覆盖范围。
这个问题的通常答案是尽可能多地测试您的自动化测试环境可以处理的变体,并且您可能会为设置和维护而烦恼。如果您的测试服务提供商同时为您使用多个版本的 Ruby - 例如,您正在使用 Travis - 那么测试多个版本相对便宜。因此,您也可以尽可能多地了解您希望“在野外”看到的环境变化,因为您可能会费心去看。