[rspec-users] testing capistrano tasks

Mike Gaffney mr.gaffo at gmail.com
Wed Jan 28 10:01:53 EST 2009

We actually have a machine that is a perfect clone of the production 
machine. The only difference is the passwords. We test all deployments 
to it first. We call it staging. Having a staging has 2 benefits:
1) We can test our deployment scripts, migrations, etc on as close as we 
can get to production.
2) If the production box dies, we have one that can take it's place very 
quickly (change the database passwords/pointers and go).

We also have a demo box that is updated via capistrano whenever the 
build passes.

Testing configuration / deployment is hard because you can assert that 
the config is what you think it is, but that in no way proves that it's 
actually working. It's like using mocks to build up functionality 
against a mock library. At some point you actually have to test against 
the real thing or you're just guessing.


Matt Wynne wrote:
> On 27 Jan 2009, at 17:08, Brian Takita wrote:
>> On Tue, Jan 27, 2009 at 4:15 AM, Matt Wynne <matt at mattwynne.net> wrote:
>>> Not done it, but Cucumber acceptance tests would surely be a good 
>>> fit here:
>>>       Given there is a database "foo"
>>>       When I run the script
>>>       Then there should be a backup no more than 10 minutes old
>>>       And the backup should restore OK
>>>       And the restored database should contain the same records as the
>>> original database
>>> On 27 Jan 2009, at 03:31, Scott Taylor wrote:
>>>> Does anyone have any insight into testing capistrano tasks?  More
>>>> specifically, I'm looking to add regression tests to this package, 
>>>> which
>>>> adds database backup tasks to capistrano:
>> 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?
>> There is some benefit though. You do get to see a list of the shell
>> commands that are run in one place. However, there can be many
>> permutations of logic inside of a deploy, so its often difficult to
>> capture every situation.
>> I realize that this sounds terrible, and perhaps there is a better way
>> to go about this, but this has been my experience.
>> IMO, the best way to test Capistrano is to have a staging environment
>> that simulates your production environment where you deploy to and
>> make sure things work.
>> I can't recall a situation where I had non-obvious issues that would
>> have been prevented with unit tests. Often times, non-obvious issues
>> are related to properly restarting processes because the monit + shell
>> script interactions had issues. This is testable, of course.
> That's why I suggested *acceptance tests* in Cucumber. I don't think 
> mocking / unit testing is going to get you much value here - what you 
> need is something that feeds back whether the whole thing works. So 
> yeah you'll need a sandbox / staging environment for that.
> Matt Wynne
> http://blog.mattwynne.net
> http://www.songkick.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list