Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


guard-de: Red / Green / Refactor / Commit #321

rking opened this Issue · 5 comments

3 participants



I'd like to add a custom command or two to guard. Is this possible? Is it desirable?


("Wait wait, tell me more!")

I'm working on some new (to me) REPL-based workflows, in particular trying to make a sweet red/green/refactor loop. That loop is currently starting to shape up with pry-rescue automatically putting me into the REPL whenever I get a test failure. However, I'm writing to talk about the next step, after each succesful {test fail ⇒ test pass} stage.

There are basically three courses of action:

  1. Refactor what you did.
  2. Start over again writing another failing test.
  3. Commit to VCS.

For the refactor case, I imagine a guard command like refactor and would run:
${VISUAL:-${EDITOR:-vim}} $(git status --porcelain | cut -b4-) "$@"

For new failing test, perhaps it would be a command that would open to the spec with the most recent timestamp? Maybe the syntax would be like:
another spec
(which would descend through spec/ looking for the most recent file. This would be generic enough that you could use it for editing files in entirely different workflows.)

For the commit to VCS, it could maybe just be ^Z and do some git commands in the background. Not sure if any guard integration would be useful (though if it showed a git status after every all-tests-passed it might be useful).

So I need your guidance on how to do this the right way.

Is there any kind of user-defined command mechanism in place? If so, would anyone be interested in co-developing this small piece as a gem? (I'm happy to do most of the work, but if I had other input I could do it with more clarity.)

Should I instead focus on the RSpec runner, and leave Guard alone? I could accomplish those same 1/2/3 paths mentioned above by merely causing RSpec to do more than say "0 failures".



There are some very interesting ideas that could make developers life much easier.

All the success/failed logic is within each Guard plugin and not Guard itself, so test related Guard plugins like guard-rspec, guard-test, guard-cucumber and guard-jasmine handles the BDD cycle on their own. You could add some hooks to these Guard plugins, so you can do some stuff when something interesting happens. Hooks can also pass arguments, so you can easily add hooks for failed, success, fixed, etc to the Guard plugins of your choice.

I think it's a good idea to not add specific commands to the interactor, but extend it in a way that custom commands can be registered, something like:

interactor :coolline do
  command :refactor do
    `${VISUAL:-${EDITOR:-vim}} $(git status --porcelain | cut -b4-) "$@"`

Custom commands and detailed hooks would allow a customizable workflow. I can take care of the interactor enhancement, since I anyway had plans for such a feature.

It should be possible to develop a Guard plugin, which adds some predefined interactors and hooks to other plugins, but there is certainly room for improvement to provide some better abstractions for these kind of plugins.


Couldn't agree more ;)


Sounds wonderful. Let me know if you want to have me monkeying around trying to make the Pull Req.

@netzpirat netzpirat was assigned

You could make the pull requests with the hooks to each Guard plugin, I'll add the interactor commands.


Pry has landed in 1.5.0, which enables you to customize the Guard interactions to your needs.

@netzpirat netzpirat closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.