关于设置工作 Guard-RSpec 示例项目的问题

Question

我正在尝试使用 guard-rspec 设置一个工作 ruby​​ 项目。

我将tutsplus tutorial 的通用方法与RSpec videos 和another post 中描述的一些新语法混合在一起。该项目可以在github 的stack-overflow-question 分支中找到。

我也在尝试按照Programming Ruby 1.9 中的描述练习命名空间。所以最终我希望在我的lib/example/ 目录中有example.rb。

关于我的项目，我有 4 个问题：

1. 我需要在我的Guardfile 中添加什么来查看我项目中的特定目录的更改？我有几种不同的方式，可以在我的Guardfile 中看到为 cmets 标记如下：

# Watch Specific Directory Attempt X

1. 在我的Guardfile（Uncomment and set this to only include directories you want to watch）中取消注释第 8 行和第 9 行并添加像 watch(%r{^lib/(?<path>.+)\.rb$}) { |m| "spec/lib/#{m[:path]}_spec.rb" } 这样的“命名组捕获”（如 here 所述）有什么区别

2. 我需要将--clear 选项放在哪里才能使其持久化？我知道我可以使用像 bin/guard --clear 这样的 binstub 来运行它，我已经尝试将它放在我的 Guardfile 中，但是它没有用。

3. 您在我的项目中是否发现任何明显的约定、语法或清晰度错误？我觉得我正在把整个事情都录音在一起，我希望能得到一些指导，以合理的方式将这些事情拼凑起来。

Answer 1

我将回答标题中的问题，并在我进行的过程中涵盖“子问题”。

1. 设置项目的最佳方式（截至目前）是使用bundle exec guard --init rspec。这应该提供合理的默认值以立即开始工作。它并不完美，但有很多工作计划进行改进，所以请改为在 GitHub 上提问（更有意义）。

2. Guard 必须保持向后兼容性，所以现在有一些“非直观”的东西，首先浏览所有文档（和 wiki）是快速了解可用内容和位置的良好投资。在困惑或有疑问时询问也是一个好主意（最好每个问题一个问题）。

3. Guard 使用 DSL 来简化侦听器的设置。这有时有点不直观和笨拙，但它确实有助于将操作组织成组，这有助于维护复杂的工作流程。 DSL 的命令，例如clearing 终端自动为：(clearing: on)。 （这回答了问题 3）。

4. 有各种各样的用途和场景，所以Guard努力让每个人都开心，也在每个平台上。 Guard 使用 Listen，它递归地监视目录（主要是由于 OSX 的限制）。这通常不是问题，但对于 OSX 上的大方向来说，这可能非常非常慢。这就是为什么 Guard 允许您选择要观看的顶级目录（例如“lib”、“app”等）。看整个项目目录很方便，所以还是默认的。有关这方面的更多信息，请参见 Listen 项目。因此默认情况下，所有目录（:directories 语句）都受到“物理监视”（占用操作资源），但在 Guard 中，您只需配置要响应的更改（watch 语句所做的）。

5. 所选择的词有时有点误导。例如。 DSL 中的watch 实际上意味着：“在所有发生的变化中，选择匹配的变化......”。传递给watch 的块会得到匹配的结果。该块应该返回当前保护插件运行的文件列表。因此，“观看”可能更具误导性而不是帮助。 "match" 可能是一个更好的选择，将来可能会取代 "watch"。

6. guard-rspec 项目在更改的文件上运行 RSpec。如果您使用调试选项运行警卫，您可以看到确切的 RSpec 命令，例如bundle exec guard -d。为了简化设置，Guard::RSpec 使用了一个 DSL，如果你的项目遵循给定的设置，它应该可以开箱即用。例如。 dsl.watch_spec_files_for(ruby.lib_files) 定义为 here：因此，如果您将所有经过测试的源文件放在 lib 中，它几乎已经可以满足您的需求。对于其他文件夹，您可以添加自己的文件夹。例如。 Rails 项目通常在 app 目录中也有源代码，因此在默认的 Guard::RSpec 模板中有一条语句：dsl.watch_spec_files_for(rails.app_files)，其模式定义为：rails.app_files = %r{^app/(.+)\.rb$} 如果您有一个未涵盖的典型案例，在该项目中打开一个问题。 （涵盖问题 2）。

示例项目中的一切看起来都很好，建议主要基于品味或偏好。例如

• 我会使用 RSpec 的隐含 subject 而不是 let (:greeter) { Example::RSpecGreeter.new }（但有些人可能会认为它不那么明确且可读性较差）
• 如果您正在测试 Example::RSpecGreeter，我建议将该类放在单独的文件中并包含它 (require 'example/rspec_greeter')
• 您可以添加 RubCop/Guard::RuboCop 来检测约定问题（涵盖第 4 个问题）
• 您可能想查看 Guard 自己的 Guardfile，该Guardfile 用于测试自己以获得更“真实”的设置，而不会出现文档混乱。
• 为了获得最佳效果，我认为最好复制整个现有项目并重命名要更改的部分。通常需要花费很多时间来微调 Travis 的备用 RSpec 配置、特殊的 gem 发布任务、某些变通方法和便利等。