小编Lei*_*eif的帖子

在ruby-doc上,文档条目File::exist?和File::exists?不同的语义重复:一个条目表示返回trueif file_name是一个目录; 另一个说true如果file_name是文件则返回.

我认为这两个条目都不正确.这两种方法似乎都是在file.cusing 中实现的rb_file_exist_p,fstat()如果传递的值是IO,或者stat()它是一个字符串,它似乎试图调用.双方fstat()并stat()返回0成功和-1误差,这是传回rb_file_exist_p,并变成了一个布尔结果.在我看来,这

1. 有两种方法可以更容易地读取代码; 没有语义差异
2. 既不存在与存在的文件有关,也与文件类项目是否存在有关,例如文件,目录,套接字,FIFO等.
3. 也许文档可以说方法告诉调用者是否存在具有类文件语义的东西,但更具体的测试将告诉它实际是什么:例如目录？,文件？,套接字？等等

我对方法中(缺乏)差异的理解是否正确,是否值得建议对文档进行更改？

我正在编写一些rspec来测试某些模块正确实现其行为。

该模块如下所示：

module Under::Test
  def some_behaviour
  end
end

我不能在RSpec中做到这一点：

describe Under::Test do
  subject {Class.new{include described_class}.new}

在#described_class被调用时，由于self是Class的实例，没有#describe_class方法，因此无法再解决它。所以我不得不重复自己：

subject {Class.new{include Under::Test}.new}

或以与客户使用方式不同的方式在规范中使用它：

subject {Object.new.extend described_class}

这具有相同的最终效果，但是我内心深处认为，如果我要我的客户要求include Under::Test，那么测试应该看起来尽可能地接近他们使用它们的方式。

我可以使用闭包属性来解决此问题，但我想知道这是否更好。这有代码气味吗？

describe Under::Test do
  subject {mudule = described_class;Class.new{include mudule}.new}

  it 'has some behaviour' do
    expect(subject.some_behaviour).to be
  end
end

注意，我在r / ruby​​上的reddit上也问过，有人建议：

subject {Class.new.include(described_class).new}

这可能就是我的去向。

我寻找这个高点和低点，特别是具有依赖项和任务参数的 RSpec rake 任务 - 找到了答案并帮助后代

基本上我想按标签过滤测试，并传入我用于某些特定于应用程序的行为的触发器。

bundle exec rake spec[some_tag,some_trigger]

我想依赖 :clean 和 'test-reports' 任务