Feature request: automatically discovering dependencies

[e2]

E.g. if an rb file is modified, it should run all the specs including that file if there are no other matches.

This is most useful for specs not tied to a single *.rb file, e.g. specs with shared examples, or when names do not map directly between impl <-> spec.

[webhat]

I don't know if this should be tagged here, and whether my methodology is sound.

I work with dummy apps in my modules for testing, mostly in spec/rails-app. Each also contains it's own running guard, separated in my top level Guardfile with ignore %r{^spec/rails-app/}. I would actually like changes in my lib/ dir to trigger specs for classes in my dummy app which implement specific functionality in the library.

Currently I run all the specs in the dummy app, by touching spec/rails-app/spec/spec_helper.rb

Here's an example of what I currently do: https://github.com/webhat/paperclip_montage https://github.com/webhat/paperclip_montage/blob/master/config/Guardfile https://github.com/webhat/paperclip_montage/blob/master/spec/rails-app/config/Guardfile # ignore the broken watch on %r{../../lib/paperclip/(.*).rb}

[e2]

@webhat - I have some suggestions, if I understood correctly.

• instead of touching the spec/rails-app/spec/spec_helper.rb it would probably be more semantically correct to touch a special file watched by the dummy app, e.g. spec/rails-app/rerun_specs or something.
• since you are watching to touch a file (and not run specs on it), that watch rule semantically doesn't belong in an :rspec guard to me - it's rather a better fit for a :shell guard.
• Guard::RSpec has recently grown a :chdir option, which lets you run RSpec from within a selected directory (useful if you have submodules with independent RSpec configs/ indepedendent spec_helpers, etc.) This would theoretically let you handle everything within a single guard. If it doesn't work as expected, file an issue. Unless of course you want to run both specs in parallel.
• I'm guessing in the dummy app you should have a directories(%w(. ../..)) statement.
• I'm a bit allergic to ignore statements on non-git-ignored type files - so I'd prefer to define a specific list of directories every time. This of course can't be done, since you want to watch spec/spec_helper.rb along with spec/rails-app. But ... if you consider that spec/rails-app have nothing to do with specs in spec, it makes sense to move them to another folder, e.g. dummy/rails-app or integration/rails-app, etc. Which allows you to watch each directory separately (and so you don't have to worry about ignore rules).

Actually, something like the touch would be "built-in" part of a "workflows" feature (Guard 3.x?) - and an example of triggers is here: https://github.com/guard/guard/issues/649

In short, I want people to be able to send "signals" or "events" directly to plugins, because there's no sense in queuing filesystem events to do the same. If you used one Guard instance for both tests, you could do what the change Pry does (simulates a changed file by queuing the change directly as a Guard action).

A lengthy response from me (as usual) - let me know if I've said anything useful. Or if I misunderstood something.

[webhat]

:+1: :chdir is exactly the option I was looking for, is there an example of it's usage?

[e2]

Nope - probably should be documented, but then again - it doesn't have too much magic behind it from a user's perspective.

If your app is e.g. broken down into modules and each has a spec dir, this is how they can be managed from one Guardfile:

%w(frontend backend api).each do |dir|
  group dir.to_sym
    guard :rspec, chdir: dir do
      watch(%r{^#{dir}/spec/.+_spec\.rb$})
    end
  end
end