[Backgroundrb-devel] Yet Another Problem with BackgroundRB

Mason Hale masonhale at gmail.com
Mon Jan 22 17:24:43 EST 2007

I definitely see a lot of opportunity in improving the test support of

The tests I have written start a worker in the test using
MiddleMan.new_worker and then check its results (stored in a database)
externally. [Note: there are some issues with the ResultsWorker at present
that make it unreliable as a means of checking
the state of your worker processes, thus all state is stored in a database.]

This has the advantage of testing the full stack in a real-world-ish
scenario. It has the downside
that it only works with relatively simple workers.

Here's an example:

==  /test/unit/backgroundrb_test ============

require File.dirname(__FILE__) + '/../test_helper'

class BackgroundrbTest < Test::Unit::TestCase

  def setup
    # start backgroundrb server
    `../../script/backgroundrb start`
    puts "starting backgroundrb server..."
    sleep 2 # give it time to startup

  def teardown
    # stop backgroundrb server
    `../../script/backgroundrb stop`
    puts "backgroundrb server stopped"

  def test_drb
    keys = []
    10.times do |i|
      key = MiddleMan.new_worker(:class => :example_worker)
      puts "Started process: #{key}"
      keys << key

    keys.each_with_index do |k, i|
      puts "Checking #{k}"
      mm = MiddleMan[k]
      assert_not_nil mm, "checking job_key #{k} on iteration #{i}"
      puts "found job: #{mm}"
      mw = MiddleMan.worker(k)
      assert_not_nil mw, "checking job_key #{k} on iteration #{i}"
      puts "found worker: #{mw}"



This test just creates 10 workers and then makes sure they are reachable
later via the generated job keys.

The test could just as easily create a worker, sleep for a few seconds to
it do it's work, then check the database for the results.

I have adopted a habit of writing dead-simple workers, where all work is
done via an external class, either
a model class or library that is loaded by the worker. I can then test these
classes independently
because they do not have a dependency on running within or being loaded by
the backgroundrb_server.
The worker should just extract the params it needs from the args passed to
it, instantiate/load the object/class it needs to
do it's work -- and then call a method on that object/class. These external
objects can be tested normally.

The tricky part is checking the results of a separate process. I use a
database for as a medium for that now.
I don't have a way to test a worker in the same process, although I'm sure
that can be worked out.

This setup is not ideal, and it won't work for everyone, but for now it's
workable for me.


On 1/22/07, Mike Aizatsky <mike.aizatsky at gmail.com> wrote:
> Mason,
> How do you test your workers in development?
> On 1/22/07, Mason Hale <masonhale at gmail.com> wrote:
> > That sounds like a BackgroundRb bug.
> >
> > FWIW -- I've got a production backgroundrb app running smoothly,
> > but I use the RAILS_ENV setting in the backgroundrb.yml to
> > set it to a production environment. I do not use the -r setting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070122/24627658/attachment.html 

More information about the Backgroundrb-devel mailing list