Testing with AMQP

[Daniel DeLeo]

Hi,
I'm wondering if anyone can share their experiences with testing AMQP
code. For now, I'm using a helper method that runs AMQP related code
inside an EM.run block. This helper method uses EM.defer to setup a
thread that sleeps a short time and then calls AMQP.stop and EM.stop.

1) I'm noticing some (lots of, actually) flakiness with the setup
described above. Does anyone have a better way?
2) I know it's considered bad form to have unit tests depend on
anything external, i.e., the AMQP server. Are there any libraries out
there to mock AMQP such that I can test that my code correctly set up
a binding or published to a topic? Would RosettaQueue work for this?
I don't want to use rosetta queue for my actual messaging.

Thanks,
Dan

[Aman Gupta]

One technique you can use is to run your tests inside a Thread and
stop and pause that thread while you wait for results:

th = Thread.current
msg = nil
queue.pop{ |m|
msg = m
th.wakeup
}
Thread.stop
assert_equal(m, 'something expected')

Aman

[Aman Gupta]

Also see http://github.com/tmm1/em-spec and http://github.com/methodmissing/em-spec
for wrappers which use this technique (and Fibers instead of Threads
if available) with bacon and rspec.

Aman

[Daniel DeLeo]

Since I was already using rspec, I opted for the methodmissing
version. Unfortunately, it spews stack traces everywhere, but I worked
out a fix for that. Anyone who's interested can see my fork @

http://github.com/danielsdeleo/em-spec/tree/master

Also sent a pull req to methodmissing for the fix since I'm not sure I
want to maintain a fork long-term.

Cheers,
Dan

On Apr 19, 5:40 pm, Aman Gupta <themastermi...@gmail.com> wrote:
> Also seehttp://github.com/tmm1/em-specandhttp://github.com/methodmissing/em-spec

[Aman Gupta]

Thanks, I will merge these patches into em-spec shortly.

Aman

[Daniel DeLeo]

Aman,

There is an unresolved issue with the patch I contributed to, namely,
that test failures inside any EM block, such as EM.add_timer, etc.
fail the entire rspec process and prevent any further examples from
running. I have a solution for this that also replaces all of the
monkey patching of rspec's internals with an overloaded #instance_eval
and also eliminates the use of globals.

This patch is mostly ready to go, but I'd like to ask about your API
preference first (any lurkers who are interested, chime in!):
1) The cleanest way is something like
describe MyEventedCode, "when using EventMachine" do
include EMSpec
...
end

2) If you have a strong preference for the EM.rspec MyEventedCode
style API, I can make it happen but this requires a bunch of monkey
patching and excess code just to handle the case where the rspec
example is not using EM and doesn't call #done, because EM specific
code is loaded into rspec globally.

Opinions?

Thanks,
Dan

p.s., patch so far is here, I deleted and re-forked:
http://github.com/danielsdeleo/em-spec/tree/master