On Jan 27, 2009, at 12:08 PM, Brian Takita wrote:
On Tue, Jan 27, 2009 at 4:15 AM, Matt Wynne <[email protected]>
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.
You can also do an integration test by deploying to localhost or to a
test box. You can then ensure that the actual db dump exists and
properly restores.
I'm sorry about the rambling infoflood/rant. I hope it is useful. :-)
It's is useful - thanks Brian.
Unfortunately the bug involves the listing which comes out of an "ls"
command, and a subsequent rm -rf of an old backup file, so it looks
like I'll have to do some sort of local deploy strategy.
Thanks for the info,
Scott
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
