[rspec-users] testing capistrano tasks

Scott Taylor scott at railsnewbie.com
Wed Jan 28 13:44:54 EST 2009

On Jan 28, 2009, at 10:01 AM, Mike Gaffney wrote:

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

Well, it's actually even trickier than that, because I'm not only  
deploying one app to one machine, but am writing a library, which  
could be used for any number of apps to any number of machines (which  
certain assumptions - i.e. a unix machine with mysql, etc.)

I've tested it locally (and by that I mean, on a staging slice), but  
when I fix a bug in the library without writing a test, there is  
absolutely no regression ability going forward.

Looks like establishing the test harness will the most tricky thing.   
As usual, writing the first test is the hardest.


More information about the rspec-users mailing list