On 27 Jan 2009, at 17:08, 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.
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
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
