amqp-spec 0.1.11 → 0.1.12

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
data/HISTORY CHANGED
@@ -53,3 +53,7 @@
53
53
  == 0.1.11 / 2010-10-18
54
54
 
55
55
  * Optional delay added to done
56
+
57
+ == 0.1.12 / 2010-10-18
58
+
59
+ * README extended
data/README.rdoc CHANGED
@@ -152,6 +152,57 @@ when including AMQP::Spec, and same caution about using them applies.
152
152
 
153
153
  ...
154
154
 
155
+ ==General notes
156
+
157
+ For a developer new to evented specs, it is not easy to internalize that the blocks given to asynchronous
158
+ methods are turned into real callbacks, intended to fire some time later. It is not easy to keep track of
159
+ the actual execution path of your code, when your blocks are supposed to fire and in what sequence.
160
+ Take the following spec as an example:
161
+
162
+ it 'receives published message' do
163
+ amqp do
164
+ q = MQ.queue('queue_name')
165
+ q.subscribe do |hdr, msg|
166
+ msg.should_not == 'data'
167
+ end
168
+ MQ.queue('queue_name').publish 'data'
169
+ q.unsubscribe; q.delete
170
+ done
171
+ end
172
+ end
173
+
174
+ Seems like a straightforward spec: you subscribe to a message queue, you set expectations inside
175
+ your subscribe block, then you publish into this queue, then you call done. What may be wrong with it?
176
+ Well, if you happen to use this spec against live AMQP broker, everything may be wrong.
177
+ First, communication delays. There is no guarantee that by the time you publish your message, the queue
178
+ have been either created or subscribed to. There is also no guarantee that your subscriber received
179
+ the message by the time you are unsubscribing and deleting your queue.
180
+ Second, sequence of your blocks. Remember, they are delayed callbacks! Don't just assume your previous
181
+ block is already executed when you start your new asynchronous action. In this spec, when done is called,
182
+ it stops everything before your subscribe callback even has a chance to fire. As a result, you'll get a
183
+ PASSING spec even though your expectation was never executed!
184
+
185
+ How to improve this spec? Allow some time for async actions to finish: either use EM timers or pass
186
+ :nowait=>false to your asynch calls to force them into synchronicity. Keep in mind the sequence in which
187
+ your callbacks are expected to fire - so place your done call at the end of subscribe block in this
188
+ example. If you want to be paranoid, you can set flags inside your callbacks and then check that they
189
+ actually fired at all AFTER your amqp/em block. Something like this will do the trick:
190
+
191
+ it 'receives published message' do
192
+ amqp do
193
+ q = MQ.queue('queue_name')
194
+ q.subscribe do |hdr, msg|
195
+ @subscribe_fired == true
196
+ msg.should == 'data'
197
+ done {q.unsubscribe; q.delete}
198
+ end
199
+ EM.add_timer(0.2) do
200
+ MQ.queue('queue_name').publish 'data'
201
+ end
202
+ end
203
+ @subscribe_fired.should be_true
204
+ end
205
+
155
206
  ==Limitations
156
207
 
157
208
  AMQP-Spec can be currently used with rspec only. I suppose, there is nothing special in extending EM-Spec's
data/VERSION CHANGED
@@ -1 +1 @@
1
- 0.1.11
1
+ 0.1.12
@@ -12,10 +12,7 @@ def publish_and_consume_once(queue_name="test_sink", data="data")
12
12
  q.subscribe do |hdr, msg|
13
13
  hdr.should be_an MQ::Header
14
14
  msg.should == data
15
- EM.next_tick {
16
- q.unsubscribe; q.delete
17
- done
18
- }
15
+ done {q.unsubscribe; q.delete}
19
16
  end
20
17
  EM.add_timer(0.2) do
21
18
  MQ.queue(queue_name).publish data
@@ -34,11 +31,10 @@ context 'Evented AMQP specs' do
34
31
  p default_options
35
32
 
36
33
  it_should_behave_like 'SpecHelper examples'
37
- it_should_behave_like 'timeout examples'
38
34
 
39
35
  context 'inside embedded context / example group' do
36
+
40
37
  it_should_behave_like 'SpecHelper examples'
41
- it_should_behave_like 'timeout examples'
42
38
  end
43
39
  end
44
40
 
@@ -61,6 +61,7 @@ shared_examples_for 'SpecHelper examples' do
61
61
  end
62
62
 
63
63
  it_should_behave_like 'done examples'
64
+ it_should_behave_like 'timeout examples'
64
65
  end
65
66
 
66
67
  shared_examples_for 'Spec examples' do
metadata CHANGED
@@ -1,13 +1,13 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: amqp-spec
3
3
  version: !ruby/object:Gem::Version
4
- hash: 13
4
+ hash: 3
5
5
  prerelease: false
6
6
  segments:
7
7
  - 0
8
8
  - 1
9
- - 11
10
- version: 0.1.11
9
+ - 12
10
+ version: 0.1.12
11
11
  platform: ruby
12
12
  authors:
13
13
  - Arvicco