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. :-) Brian >> >> http://github.com/smtlaissezfaire/cap_db_dump/tree/master >> >> Scott >> >> _______________________________________________ >> rspec-users mailing list >> [email protected] >> http://rubyforge.org/mailman/listinfo/rspec-users > > Matt Wynne > http://blog.mattwynne.net > http://www.songkick.com > > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
