[rspec-users] testing capistrano tasks

Stephen Eley sfeley at gmail.com
Tue Jan 27 15:23:45 EST 2009

On Tue, Jan 27, 2009 at 12:08 PM, Brian Takita <brian.takita at gmail.com> wrote:
> Yes, I have experience testing capistrano. My experience with unit
> testing Capistrano has been less than positive. Capistrano is
> difficult to test. Basically you have to mock out the shell/run/file
> transfer commands to do unit tests. The big problem is how do you know
> the shell commands are correct?

Well, you could test them separately in their own unit tests.  Write a
spec, run it, look for expected output.

But the bigger question to me is, unless you're *developing*
Capistrano or writing fundamental new tasks for it, why unit test it?
To me that's a bit like taking apart my car to test the pieces; I find
it more sensible to assume (correctly or not) that they've already
been tested at the factory.  Integration testing seems a lot more
appropriate for a typical deployment, even a complex one.  I don't
really care what shell commands get run; I care that the end result
puts the expected stuff in the expected locations for the inputs I
intend to give it, and executes the expected commands.

Either way, though, I'd think it would be pretty easy to test in RSpec
*or* Cucumber.  You could even use Webrat to help.  Set up a staging
URL, write a stupid little Rails or Sinatra app with a single
controller that spits out different known values before and after
deployment, run your cap recipe inside your spec, and hit the URL to
see if it changed.  Add wrinkles as necessary for whatever special
thing you're testing that's important to your situation.  (If you care
about file contents or locations, your Rails controller could show
grep results or checksums.  If you care about DB migrations, write
simple migrations to change DB values and return those.  Etc.  The
micro-app doesn't have to be elegant or proper.  It's not the thing
being tested.)

Does that make sense?  I haven't bothered with this sort of thing much
because my deployments are never the weird part of my applications,
but it seems straightforward.  One thing we tend to forget if we're
too MVC-Web-focused is that RSpec can test *anything* you can express
in Ruby.  And you can use Ruby to do anything you can do in the OS.
So it's a lot more flexible than just hitting models and controllers.

Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine

More information about the rspec-users mailing list