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

Closed
rking opened this Issue Sep 5, 2012 · 5 comments

Comments

Projects
None yet
3 participants
@rking

rking commented Sep 5, 2012

tl;dr

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

ww;tmm

("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".

Thanks!
—☈

@netzpirat

This comment has been minimized.

Show comment Hide comment
@netzpirat

netzpirat Sep 6, 2012

Contributor

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-) "$@"`
  end
end

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.

Contributor

netzpirat commented Sep 6, 2012

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-) "$@"`
  end
end

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.

@thibaudgg

This comment has been minimized.

Show comment Hide comment
@thibaudgg

thibaudgg Sep 6, 2012

Member

Couldn't agree more ;)

Member

thibaudgg commented Sep 6, 2012

Couldn't agree more ;)

@rking

This comment has been minimized.

Show comment Hide comment
@rking

rking Sep 7, 2012

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

rking commented Sep 7, 2012

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

@ghost ghost assigned netzpirat Sep 7, 2012

@netzpirat

This comment has been minimized.

Show comment Hide comment
@netzpirat

netzpirat Sep 7, 2012

Contributor

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

Contributor

netzpirat commented Sep 7, 2012

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

@netzpirat

This comment has been minimized.

Show comment Hide comment
@netzpirat

netzpirat Oct 22, 2012

Contributor

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

Contributor

netzpirat commented Oct 22, 2012

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

@netzpirat netzpirat closed this Oct 22, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment