On Wed, Feb 18, 2009 at 3:02 PM, Ben Mabey <b...@benmabey.com> wrote: > > One option is to use ARMailer[1] to queue your mail. As long as your > selenium process and test process are using the same DB without transactions > getting in the way then ARMailer should work fine for what you want to do.
Is changing production infrastructure solely for the sake of making tests work a recommended practice? To me it feels a bit backwards. Raimond: I can't address the problems you're having with Polonium, as I'd never heard of it until this thread (and Googling it was surprisingly hard; I finally found http://github.com/pivotal/polonium). But it does seem to me like Webrat and its various dependencies all manage to break each other's APIs with every minor release, so this doesn't surprise me. I've had to roll back versions of Nokogiri several times for things like this. If you're at the level of integration testing, checking ActionMailer.deliveries may not be the way to go anyway. I'd look instead to see if the e-mails were actually sent. As I see it, even if ActionMailer thinks it's done its job, mail could still fail for other reasons and that's a failed system interaction. Here's an idea I've seen that's independent of delivery method; it's basically just overriding the ActionMailer recipients in test mode so that all e-mails go to one address: http://www.dweebd.com/ruby/capture-actionmailer-output-for-your-qa-team/ >From that point, your tests could use Ruby's standard mail libraries to retrieve the mail and scan it, or scrape 'mail' from the shell, or read the entrails of your enemies, or whatever else you like to confirm that the right stuff is in the message. -- Have Fun, Steve Eley (sfe...@gmail.com) ESCAPE POD - The Science Fiction Podcast Magazine http://www.escapepod.org _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
